[Cs-dev] 0dbfs and floating output

[Cs-dev] 0dbfs and floating output

Date	2013-05-26 03:56
From	Pete Goodeve
Subject	[Cs-dev] 0dbfs and floating output
Attachments	None

Date	2013-05-26 09:24
From	Richard Dobson
Subject	Re: [Cs-dev] 0dbfs and floating output
	The ± 1.0 range f/p range is in fact very much standard in software audio (both VST and CoreAudio, at least, are predicated on it, and it is pretty much standard for portaudio too). In all cases, the values are internally converted to whatever final stream format is required (file or dac). All that is handled transparently by Csound (or portaudio). I am surprised to hear that any mixer cannot handle normalised floats in this way. VST now supports a double-precision format for plugins, still naturally over the ± 1.0 range. The 0dbfs system was introduced to overcome the fact that the original version of Csound (predating most file formats!) did ~appear~ to be dealing with integers (the ± 32768 range); though of course all Csound's computation was then, as now, in f/p. But it was for all practical purposes a literal sample range - values were written unchanged to disk. This meant, in effect, your orchestra code decided what your sample range was - quasi 16bit, quasi 24bit, f/p, etc. If you wanted to change the output resolution, you had to modify your Csound code. The only reason, indeed, that the default option for Csound is the 32768 range is to preserve backwards compatibility. Really, the standard range should be normalised floats. Internally, the 0dbfs range (whatever it is set to) is used when writing samples in the requested output format - 16bit , 24bit floats, etc. So you can run your orchestra into alternative files format with no change needed in the code, just the file format selection command flag. One other advantage of the f/p range, as you hint, is that yes, indeed, over-range samples can be written. This is also recognised in VST, DirectSound etc standards, where over-range values are supported, but they will of necessity be clipped at the final point of rendering via the soundcard. For example, in the command line player "paplay" I include in the CDP Multichannel Toolkit, so long as the PEAK chunk is written (which currently is supported as standard in libsndfile only for f/p formats), the player automatically rescales the sample stream, so that the playback will be clean. In the context of experimental software, such flexibility is well-nigh essential! Richard Dobson On 26/05/2013 03:56, Pete Goodeve wrote: > Hi all, > I noticed a recent thread in Nabble's Csound-General list > regarding 0dbfs and clipping, which prompted a related > concern of mine. As I'm not subscribed to that list > [too many lists already...] I'd like to bring it up here. > > It seems to me that the 0dbfs scheme was designed in > the days when most or all output was integer, but I'm > not sure it is being applied to float values in the > best way. > > When you are working to a maximum integer limit that > can't be exceeded, it seems right to be able to set > 0dbfs to the level that corresponds to that limit, > so that generated signals can be scaled to that, and > you get warned if it is exceeded. > > However, I find that the 0dbfs setting is also used to > scale floating output values -- so that the level > correponding to '0' dbfs is always rescaled to '1.000'. > When this output is going to a mixer -- as is usual in > real-time preformance, I guess -- it can be frustrating > because this may be insufficient to get a decent final > level, unless all the faders in the chain are set to > maximum. > > In practice I overcome this by using a 0dbfs of less > than 1, but as a consequence I get many many "out of > range" messages. It was a while before I realized > that these were totally meaningless! Only the levels > after the mixer chain are relevant to clipping and > distortion. > > I think there ought to be some decoupling here. > One solution would be to not scale floating output > by 0dbfs. That setting would represent only a 'desired > limit': any higher signal would just trigger an 'out of > range' report, but would not be clipped or scaled. > Then one could set the signal levels in the csd to > whatever will give a suitable level to send to the mixer. > > Alternatively, there could be either a new 'scaling' > system variable, or a command option to set the scale. > 0dbfs would then continue to scale to 1.000, but the > scaling factor would be applied after that, to raise > the actual output to a suitable level. > ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2013-05-26 09:55
From	peiman khosravi
Subject	Re: [Cs-dev] 0dbfs and floating output
Attachments	None None
	On 26 May 2013 03:56, Pete Goodeve <pete.goodeve@computer.org> wrote: In practice I overcome this by using a 0dbfs of less than 1, but as a consequence I get many many "out of range" messages. It was a while before I realized that these were totally meaningless! Only the levels after the mixer chain are relevant to clipping and distortion. Do you mean an external mixer with an analogue signal path? If so then the our of range messages are very significant. It is not the level after the mixer chain that clips, clipping occurs when the signal is converted from digital to analogue, which is before it goes into the mixer (unless you mean a software mixer). Setting 0dBfs to less than a linear amplitude of 1 and then using 1 as the maximum amplitude scale is not a good idea at all. It pretty much guarantees clipping: so if 0dBfs is set to .5 then a linear amplitude of 1 would mean +6dBfs (clips by 6dBs). If you are working with recorded audio then care must be taken to record the sound at a sufficient level anyway. And if you're processing sounds then sometimes it is necessary to gain the levels or normalise files. If you need to increase the gain then it is better to keep 0dBfs=1 and just use a scaling value of higher than one. For obvious reasons you don't want to do too much gain in the analogue domain or then you start getting noise. P I think there ought to be some decoupling here. One solution would be to not scale floating output by 0dbfs. That setting would represent only a 'desired limit': any higher signal would just trigger an 'out of range' report, but would not be clipped or scaled. Then one could set the signal levels in the csd to whatever will give a suitable level to send to the mixer. Alternatively, there could be either a new 'scaling' system variable, or a command option to set the scale. 0dbfs would then continue to scale to 1.000, but the scaling factor would be applied after that, to raise the actual output to a suitable level. What do you think? -- Pete -- ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel

Date	2013-05-26 13:56
From	Justin Smith
Subject	Re: [Cs-dev] 0dbfs and floating output
Attachments	None None
	If we are going to keep the current behavior regarding 0dbfs (using it to generate warnings but not truncating data), the manual for 0dbfs should be changed to reflect this fact: "Amplitude values in Csound are always relative to a "0dbfs" value representing the peak available amplitude before clipping." also, the page for "Using.html#AmplitudeCsound" should be changed: "Amplitude values in Csound are always relative to a "0dbfs" value representing the peak available amplitude before clipping ..." My reading of those once led me to believe that such truncation was guaranteed to happen, but the way csound interacts with floating point software mixing renders those statements false (or at least dangerously misleading). Perhaps there could be a flag to turn this truncation behavior on and off? As we have discussed previously, this is actually a health and safety risk for people who use csound with floating point software mixers. There can be situations where audio from csound is not truncated to the 0dbfs range but much louder than all other software after that mixing stage. Or failing that, some prominent warning that software mixing is not a reliable way to control csound audio output. A csound specific warning being called for since other software can be counted on to produce sane output, but csound can output anything if you have the right (wrong) code. On Sun, May 26, 2013 at 1:55 AM, peiman khosravi <peimankhosravi@gmail.com> wrote: On 26 May 2013 03:56, Pete Goodeve <pete.goodeve@computer.org> wrote: In practice I overcome this by using a 0dbfs of less than 1, but as a consequence I get many many "out of range" messages. It was a while before I realized that these were totally meaningless! Only the levels after the mixer chain are relevant to clipping and distortion. Do you mean an external mixer with an analogue signal path? If so then the our of range messages are very significant. It is not the level after the mixer chain that clips, clipping occurs when the signal is converted from digital to analogue, which is before it goes into the mixer (unless you mean a software mixer). Setting 0dBfs to less than a linear amplitude of 1 and then using 1 as the maximum amplitude scale is not a good idea at all. It pretty much guarantees clipping: so if 0dBfs is set to .5 then a linear amplitude of 1 would mean +6dBfs (clips by 6dBs). If you are working with recorded audio then care must be taken to record the sound at a sufficient level anyway. And if you're processing sounds then sometimes it is necessary to gain the levels or normalise files. If you need to increase the gain then it is better to keep 0dBfs=1 and just use a scaling value of higher than one. For obvious reasons you don't want to do too much gain in the analogue domain or then you start getting noise. P I think there ought to be some decoupling here. One solution would be to not scale floating output by 0dbfs. That setting would represent only a 'desired limit': any higher signal would just trigger an 'out of range' report, but would not be clipped or scaled. Then one could set the signal levels in the csd to whatever will give a suitable level to send to the mixer. Alternatively, there could be either a new 'scaling' system variable, or a command option to set the scale. 0dbfs would then continue to scale to 1.000, but the scaling factor would be applied after that, to raise the actual output to a suitable level. What do you think? -- Pete -- ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel

Date	2013-05-26 14:27
From	Richard Dobson
Subject	Re: [Cs-dev] 0dbfs and floating output
	There will ~always~ be clipping of values above 0dbfs when rendering to a soundcard, or to an integer file format. In these circumstances, truncation is indeed guaranteed to happen. The ~only~ circumstance in which clipping is not applied is in writing to a floats soundfile. If Csound is feeding floats into a live fx chain, the expectation of clipping at the renderer still applies, unless some other inserted process performs rescaling. As far as I can tell, there is currently no Csound command option to force clipping of floats files. The usual vigilance (by no means peculiar to Csound) of the user regarding sample levels will continue to be needed! Any number of other processes unrelated to Csound (not least those offering a gain function) can likewise cause clipping. A previous thread raised the suggestion of adding a further directive to define headroom (which would in effect calibrates Csound's 0dbfs to some level below digital peak). The point this makes is that, with the use of high-precision samples, running audio close to 0dbfs is really unnecessary and should even be regarded as an error. A 0db point even 20dB below digital peak (which is what many pro digital mixers in fact implement, though conventions do vary somewhat) is entirely reasonable. Such a level of headroom is extravagant only for 16bit streams. For 24bit and beyond it is fine and still allows a dynamic range beyond the dreams of any audiophile. Richard Dobson On 26/05/2013 13:56, Justin Smith wrote: > If we are going to keep the current behavior regarding 0dbfs (using it > to generate warnings but not truncating data), the manual for 0dbfs > should be changed to reflect this fact: > > "Amplitude values in Csound are always relative to a "0dbfs" value > representing the peak available amplitude before clipping." > > also, the page for "Using.html#AmplitudeCsound" should be changed: > > "Amplitude values in Csound are always relative to a "0dbfs" value > representing the peak available amplitude before clipping ..." > > My reading of those once led me to believe that such truncation was > guaranteed to happen, but the way csound interacts with floating point > software mixing renders those statements false (or at least dangerously > misleading). > ... ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2013-05-26 14:34
From	Justin Smith
Subject	Re: [Cs-dev] 0dbfs and floating output
Attachments	None None
	With a software mixer, it is not 0dbfs which clips, it is some arbitrary multiple of 0dbfs. On Sun, May 26, 2013 at 6:27 AM, Richard Dobson <richarddobson@blueyonder.co.uk> wrote: There will ~always~ be clipping of values above 0dbfs when rendering to a soundcard, or to an integer file format. In these circumstances, truncation is indeed guaranteed to happen. The ~only~ circumstance in which clipping is not applied is in writing to a floats soundfile. If Csound is feeding floats into a live fx chain, the expectation of clipping at the renderer still applies, unless some other inserted process performs rescaling. As far as I can tell, there is currently no Csound command option to force clipping of floats files. The usual vigilance (by no means peculiar to Csound) of the user regarding sample levels will continue to be needed! Any number of other processes unrelated to Csound (not least those offering a gain function) can likewise cause clipping. A previous thread raised the suggestion of adding a further directive to define headroom (which would in effect calibrates Csound's 0dbfs to some level below digital peak). The point this makes is that, with the use of high-precision samples, running audio close to 0dbfs is really unnecessary and should even be regarded as an error. A 0db point even 20dB below digital peak (which is what many pro digital mixers in fact implement, though conventions do vary somewhat) is entirely reasonable. Such a level of headroom is extravagant only for 16bit streams. For 24bit and beyond it is fine and still allows a dynamic range beyond the dreams of any audiophile. Richard Dobson On 26/05/2013 13:56, Justin Smith wrote: > If we are going to keep the current behavior regarding 0dbfs (using it > to generate warnings but not truncating data), the manual for 0dbfs > should be changed to reflect this fact: > > "Amplitude values in Csound are always relative to a "0dbfs" value > representing the peak available amplitude before clipping." > > also, the page for "Using.html#AmplitudeCsound" should be changed: > > "Amplitude values in Csound are always relative to a "0dbfs" value > representing the peak available amplitude before clipping ..." > > My reading of those once led me to believe that such truncation was > guaranteed to happen, but the way csound interacts with floating point > software mixing renders those statements false (or at least dangerously > misleading). > ... ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel

Date	2013-05-27 00:59
From	peiman khosravi
Subject	Re: [Cs-dev] 0dbfs and floating output
Attachments	None None
	Perhaps there could be a flag to turn this truncation behavior on and off? As we have discussed previously, this is actually a health and safety risk for people who use csound with floating point software mixers. There can be situations where audio from csound is not truncated to the 0dbfs range but much louder than all other software after that mixing stage. This can't be the case because clipping is an analogue thing: the voltage cannot exceed -1/+1 regardless of how much the software domain signal is boosted. You can try this by sending a DC offset to a speaker with a visible cone (a great educational tool to have in the classroom): linear amplitude value of 10000000 is the same as 1, which means that the speaker diaphragm is not going to move any further when you increase the signal beyond a voltage of 1. On Sun, May 26, 2013 at 1:55 AM, peiman khosravi <peimankhosravi@gmail.com> wrote: On 26 May 2013 03:56, Pete Goodeve <pete.goodeve@computer.org> wrote: In practice I overcome this by using a 0dbfs of less than 1, but as a consequence I get many many "out of range" messages. It was a while before I realized that these were totally meaningless! Only the levels after the mixer chain are relevant to clipping and distortion. Do you mean an external mixer with an analogue signal path? If so then the our of range messages are very significant. It is not the level after the mixer chain that clips, clipping occurs when the signal is converted from digital to analogue, which is before it goes into the mixer (unless you mean a software mixer). Setting 0dBfs to less than a linear amplitude of 1 and then using 1 as the maximum amplitude scale is not a good idea at all. It pretty much guarantees clipping: so if 0dBfs is set to .5 then a linear amplitude of 1 would mean +6dBfs (clips by 6dBs). If you are working with recorded audio then care must be taken to record the sound at a sufficient level anyway. And if you're processing sounds then sometimes it is necessary to gain the levels or normalise files. If you need to increase the gain then it is better to keep 0dBfs=1 and just use a scaling value of higher than one. For obvious reasons you don't want to do too much gain in the analogue domain or then you start getting noise. P I think there ought to be some decoupling here. One solution would be to not scale floating output by 0dbfs. That setting would represent only a 'desired limit': any higher signal would just trigger an 'out of range' report, but would not be clipped or scaled. Then one could set the signal levels in the csd to whatever will give a suitable level to send to the mixer. Alternatively, there could be either a new 'scaling' system variable, or a command option to set the scale. 0dbfs would then continue to scale to 1.000, but the scaling factor would be applied after that, to raise the actual output to a suitable level. What do you think? -- Pete -- ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel

Date	2013-05-27 01:16
From	Justin Smith
Subject	Re: [Cs-dev] 0dbfs and floating output
Attachments	None None
	peiman: my point is that the docs say the signal is clipped at 0dbfs, when in fact with software mixing present it is clipped by the hardware at an arbitrary multiple of 0dbfs. This results in surprising and possibly injurious output when the user has the software mixer at a low level and all other programs produce sane volume levels. My main suggestion is either change the behavior to match the docs (csound clips output at 0dbfs) or change the docs to match the behavior (in the presence of software mixing the clipping happens at the hardware limit of the audio device, regardless of software mixer settings - meaning that no matter the level you set on your computer's software volume knob csound is capable of producing full intensity output from the device). Note that in the latter case (the current behavior) the amplitude at which samples will be clipped is not csound's 0dbfs value. On Sun, May 26, 2013 at 4:59 PM, peiman khosravi <peimankhosravi@gmail.com> wrote: Perhaps there could be a flag to turn this truncation behavior on and off? As we have discussed previously, this is actually a health and safety risk for people who use csound with floating point software mixers. There can be situations where audio from csound is not truncated to the 0dbfs range but much louder than all other software after that mixing stage. This can't be the case because clipping is an analogue thing: the voltage cannot exceed -1/+1 regardless of how much the software domain signal is boosted. You can try this by sending a DC offset to a speaker with a visible cone (a great educational tool to have in the classroom): linear amplitude value of 10000000 is the same as 1, which means that the speaker diaphragm is not going to move any further when you increase the signal beyond a voltage of 1. On Sun, May 26, 2013 at 1:55 AM, peiman khosravi <peimankhosravi@gmail.com> wrote: On 26 May 2013 03:56, Pete Goodeve <pete.goodeve@computer.org> wrote: In practice I overcome this by using a 0dbfs of less than 1, but as a consequence I get many many "out of range" messages. It was a while before I realized that these were totally meaningless! Only the levels after the mixer chain are relevant to clipping and distortion. Do you mean an external mixer with an analogue signal path? If so then the our of range messages are very significant. It is not the level after the mixer chain that clips, clipping occurs when the signal is converted from digital to analogue, which is before it goes into the mixer (unless you mean a software mixer). Setting 0dBfs to less than a linear amplitude of 1 and then using 1 as the maximum amplitude scale is not a good idea at all. It pretty much guarantees clipping: so if 0dBfs is set to .5 then a linear amplitude of 1 would mean +6dBfs (clips by 6dBs). If you are working with recorded audio then care must be taken to record the sound at a sufficient level anyway. And if you're processing sounds then sometimes it is necessary to gain the levels or normalise files. If you need to increase the gain then it is better to keep 0dBfs=1 and just use a scaling value of higher than one. For obvious reasons you don't want to do too much gain in the analogue domain or then you start getting noise. P I think there ought to be some decoupling here. One solution would be to not scale floating output by 0dbfs. That setting would represent only a 'desired limit': any higher signal would just trigger an 'out of range' report, but would not be clipped or scaled. Then one could set the signal levels in the csd to whatever will give a suitable level to send to the mixer. Alternatively, there could be either a new 'scaling' system variable, or a command option to set the scale. 0dbfs would then continue to scale to 1.000, but the scaling factor would be applied after that, to raise the actual output to a suitable level. What do you think? -- Pete -- ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel

Date	2013-05-27 02:47
From	pete.goodeve@computer.org
Subject	Re: [Cs-dev] 0dbfs and floating output
Attachments	None

Date	2013-05-27 03:18
From	Justin Smith
Subject	Re: [Cs-dev] 0dbfs and floating output
Attachments	None None
	I am OK with this as long as the docs are adjusted to indicate that the clipping does not happen at 0dbfs when software mixing is involved. On Sun, May 26, 2013 at 6:47 PM, <pete.goodeve@computer.org> wrote: My post seems to have generated some discussion (:-)) which seems to me to show that there is some confusion as the the actual meaning of '0dbfs'! And I may not have been entirely clear what I meant myself... On Sun, May 26, 2013 at 09:24:50AM +0100, Richard Dobson wrote: > The ± 1.0 range f/p range is in fact very much standard in software > audio (both VST and CoreAudio, at least, are predicated on it, and it is > pretty much standard for portaudio too). In all cases, the values are > internally converted to whatever final stream format is required (file > or dac). All that is handled transparently by Csound (or portaudio). I > am surprised to hear that any mixer cannot handle normalised floats in > this way. Yes. I completely agree that this is a suitable convention -- at the point of conversion to analog or to integer recording form. So if you're feeding Csound output directly to an audio driver, you probably do want 0dbfs = 1.0, as if you exceed it, it is going to be clipped -- by the driver. Usually though (at least in my case) there is a software mixer between Csound and the driver, and this is where I was having problems. (Peiman, I was not thinking of hardware analog mixing after the audio card.) The thing is that I like to have the sliders (in my case one for Csound and a 'Master') set somewhere mid-range, so that I can adjust levels up as well as down. This means that if Csound is generating a max level of 1.0 it is considerably reduced from that when it gets to the actual audio driver. I've been doing some more detailed experimenting, and I suspect now that I can use the fader levels more intelligently. The Haiku mixer I'm usually using does have 18dB of headroom above the defined '0dB', so I could boost things if I want. I was also influenced by fluidsynth, which allows an output gain up to ~10 (presumably assuming that the integer soundfont samples have an appropriate level). I've been using a fluidsynth gain of ~5, and was having trouble matching that and Csound. The confusion I was noticing is regarding whare 'clipping' actually occurs -- or should occur. As far as I know, no application ever clips samples while they are in floating point. After all, the reason for using FP is to get a big dynamic range without needing to limit things. Clipping is only done when you have to convert to an integer format that is so limited. Csound doesn't -- and shouldn't -- clip anything it outputs as floating point. It shouldn't, because clipping is going to happen at the final conversion point anyway; any earlier clipping is likely to be at the wrong level (mixing levels etc.) and would just confuse things. -- Pete -- ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel

Date	2013-05-27 03:33
From	Michael Gogins
Subject	Re: [Cs-dev] 0dbfs and floating output
Attachments	None None
	That is fine with me. I think the documentation should say: 0dBFS is 0 decibels (maximum amplitude) at full scale. As always with decibels, which are a relative measure of energy, 0 dBFS is a nominal value. By convention, 0 dBFS is 1.0 for floating point signals, or 32768 for 16 bit integer signals. 0dBFS can be thought of as the 0 dB level on a VU meter, which is red above 0 dB, indicating that clipping or other unwanted effects may occur above that amplitude. In recording practice, of course, there is usually some usable 'headroom' above 0 dBFS and it is common for engineers to record into the red as far as possible without obvious distortion as this increases the usable dynamic range of the recording. It should be kept in mind that the meaning of the concept is somewhat different for analog signals, for integer digital signals, and for floating point digital signals. For analog signals, there is some indeterminate headroom above 0 dBFS, with the signal degrading as it runs out of headroom. For integer digital signals, there is absolutely no headroom and hard clipping occurs immediately if the signal exceeds 0 dBFS. For floating point digital signals, 0 dBFS is more of a convenience or convention. Usually it is 1.0 but there is a very great deal of headroom above that. For recording to digital floating point soundfiles, some engineers prefer to set 0 dBFS 6 or 12 decibels below 8388608, which is 0 dBFS for the 24 bit mantissa of a single precision floating point number. Such a configuration provides the most accurate and cleanest signal with the widest dynamic range possible using floating point samples. If the user wishes to limit overloading equipment down the signal chain from Csound, either an integer signal should be used with appropriate 0dbfs value, or a limiting opcode should be used. On Sun, May 26, 2013 at 10:18 PM, Justin Smith <noisesmith@gmail.com> wrote: I am OK with this as long as the docs are adjusted to indicate that the clipping does not happen at 0dbfs when software mixing is involved. On Sun, May 26, 2013 at 6:47 PM, <pete.goodeve@computer.org> wrote: My post seems to have generated some discussion (:-)) which seems to me to show that there is some confusion as the the actual meaning of '0dbfs'! And I may not have been entirely clear what I meant myself... On Sun, May 26, 2013 at 09:24:50AM +0100, Richard Dobson wrote: > The ± 1.0 range f/p range is in fact very much standard in software > audio (both VST and CoreAudio, at least, are predicated on it, and it is > pretty much standard for portaudio too). In all cases, the values are > internally converted to whatever final stream format is required (file > or dac). All that is handled transparently by Csound (or portaudio). I > am surprised to hear that any mixer cannot handle normalised floats in > this way. Yes. I completely agree that this is a suitable convention -- at the point of conversion to analog or to integer recording form. So if you're feeding Csound output directly to an audio driver, you probably do want 0dbfs = 1.0, as if you exceed it, it is going to be clipped -- by the driver. Usually though (at least in my case) there is a software mixer between Csound and the driver, and this is where I was having problems. (Peiman, I was not thinking of hardware analog mixing after the audio card.) The thing is that I like to have the sliders (in my case one for Csound and a 'Master') set somewhere mid-range, so that I can adjust levels up as well as down. This means that if Csound is generating a max level of 1.0 it is considerably reduced from that when it gets to the actual audio driver. I've been doing some more detailed experimenting, and I suspect now that I can use the fader levels more intelligently. The Haiku mixer I'm usually using does have 18dB of headroom above the defined '0dB', so I could boost things if I want. I was also influenced by fluidsynth, which allows an output gain up to ~10 (presumably assuming that the integer soundfont samples have an appropriate level). I've been using a fluidsynth gain of ~5, and was having trouble matching that and Csound. The confusion I was noticing is regarding whare 'clipping' actually occurs -- or should occur. As far as I know, no application ever clips samples while they are in floating point. After all, the reason for using FP is to get a big dynamic range without needing to limit things. Clipping is only done when you have to convert to an integer format that is so limited. Csound doesn't -- and shouldn't -- clip anything it outputs as floating point. It shouldn't, because clipping is going to happen at the final conversion point anyway; any earlier clipping is likely to be at the wrong level (mixing levels etc.) and would just confuse things. -- Pete -- ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel -- Michael Gogins Irreducible Productions http://www.michael-gogins.com Michael dot Gogins at gmail dot com

Date	2013-05-27 07:08
From	peiman khosravi
Subject	Re: [Cs-dev] 0dbfs and floating output
Attachments	None None
	On 27 May 2013 01:16, Justin Smith <noisesmith@gmail.com> wrote: peiman: my point is that the docs say the signal is clipped at 0dbfs, when in fact with software mixing present it is clipped by the hardware at an arbitrary multiple of 0dbfs. This results in surprising and possibly injurious output when the user has the software mixer at a low level and all other programs produce sane volume levels. My main suggestion is either change the behavior to match the docs (csound clips output at 0dbfs) or change the docs to match the behavior (in the presence of software mixing the clipping happens at the hardware limit of the audio device, regardless of software mixer settings - meaning that no matter the level you set on your computer's software volume knob csound is capable of producing full intensity output from the device). Note that in the latter case (the current behavior) the amplitude at which samples will be clipped is not csound's 0dbfs value. Hi Justin, OK I see. But to me that's as unlikely a scenario as someone accidentally putting their finger in the electrical socket! But let me do some testing, I use a software mixer (RMEs total mix) and have never experienced anything like this, which make me wonder if the mixer doesn't have a mechanism of truncating the input signal at 0dB. P On Sun, May 26, 2013 at 4:59 PM, peiman khosravi <peimankhosravi@gmail.com> wrote: Perhaps there could be a flag to turn this truncation behavior on and off? As we have discussed previously, this is actually a health and safety risk for people who use csound with floating point software mixers. There can be situations where audio from csound is not truncated to the 0dbfs range but much louder than all other software after that mixing stage. This can't be the case because clipping is an analogue thing: the voltage cannot exceed -1/+1 regardless of how much the software domain signal is boosted. You can try this by sending a DC offset to a speaker with a visible cone (a great educational tool to have in the classroom): linear amplitude value of 10000000 is the same as 1, which means that the speaker diaphragm is not going to move any further when you increase the signal beyond a voltage of 1. On Sun, May 26, 2013 at 1:55 AM, peiman khosravi <peimankhosravi@gmail.com> wrote: On 26 May 2013 03:56, Pete Goodeve <pete.goodeve@computer.org> wrote: In practice I overcome this by using a 0dbfs of less than 1, but as a consequence I get many many "out of range" messages. It was a while before I realized that these were totally meaningless! Only the levels after the mixer chain are relevant to clipping and distortion. Do you mean an external mixer with an analogue signal path? If so then the our of range messages are very significant. It is not the level after the mixer chain that clips, clipping occurs when the signal is converted from digital to analogue, which is before it goes into the mixer (unless you mean a software mixer). Setting 0dBfs to less than a linear amplitude of 1 and then using 1 as the maximum amplitude scale is not a good idea at all. It pretty much guarantees clipping: so if 0dBfs is set to .5 then a linear amplitude of 1 would mean +6dBfs (clips by 6dBs). If you are working with recorded audio then care must be taken to record the sound at a sufficient level anyway. And if you're processing sounds then sometimes it is necessary to gain the levels or normalise files. If you need to increase the gain then it is better to keep 0dBfs=1 and just use a scaling value of higher than one. For obvious reasons you don't want to do too much gain in the analogue domain or then you start getting noise. P I think there ought to be some decoupling here. One solution would be to not scale floating output by 0dbfs. That setting would represent only a 'desired limit': any higher signal would just trigger an 'out of range' report, but would not be clipped or scaled. Then one could set the signal levels in the csd to whatever will give a suitable level to send to the mixer. Alternatively, there could be either a new 'scaling' system variable, or a command option to set the scale. 0dbfs would then continue to scale to 1.000, but the scaling factor would be applied after that, to raise the actual output to a suitable level. What do you think? -- Pete -- ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel

Date	2013-05-27 09:11
From	Richard Dobson
Subject	Re: [Cs-dev] 0dbfs and floating output
	It would be important to know if this is a problem specific to one species of software mixer (so, handy to know what system we are talking about here), or a generic issue. It might be that such things need to be part of the main documentation rather than being tucked away inside the description of the 0dbfs opcode itself. It would for example be reasonable to assume that a software mixer receiving N inputs will scale each input by 1/N (the sum of all the signals needing not to exceed the system 0dbfs level). This may be done in two different ways - scaling at the input stage and then summing, or summing the incoming values (only reasonable in floating-point) and scaling the sum at the output. It is easy enough to see in such circumstances that the signal coming from Csound may only induce clippng at 'some arbitrary multiple of 0dbfs', given that the mixer is already attenuating it behind the scenes. Either way, a critical task whenever systems are combined is calibration. In the term "0dbfs" the "fs" means "fullscale sine" (i.e. a sinusoid spanning the min and max sample values), and is associated specifically with digital integer or fixed-point audio where there is indeed a digital peak value. As such this is of course a relative value; it does not signify in any sense an analogue voltage. In calibration, a source is set to emit a signal at (say) its nominal 0dB point, and the calibration establishes that that is the level which appears throighout the signal chain. It is of course specially important in analogue systems, but an important test to make even in an entirely digital system as the "nominal" 0dB point can still vary,(e.g. by defining different amounts of headroom. Thuis the "nominal" 0db point may be, say, 12dB below peak, or below 0dbfs. This approach is widely employed in digital mixers, and software mixers may well seek to emulate the hardware mixer by employing a similar approach. One subtle point is that 0dbfs (aka digital peak) is, literally, a peak value. The equivalent RMS level of a 0dbfs sinusoid is -3dB (think of it as the area under the curve; only with a naive digital square wave will the RMS and peak levels have the same value). Any metering which employs RMS may well show the Csound 0dbfs signal as registering at -3dB. This is one of the things to check during the calibration process (short of reading the manual, etc...). Richard Dobson On 27/05/2013 07:08, peiman khosravi wrote: > > > On 27 May 2013 01:16, Justin Smith > wrote: > > peiman: my point is that the docs say the signal is clipped at > 0dbfs, when in fact with software mixing present it is clipped by > the hardware at an arbitrary multiple of 0dbfs. This results in > surprising and possibly injurious output when the user has the > software mixer at a low level and all other programs produce sane > volume levels. > > My main suggestion is either change the behavior to match the docs > (csound clips output at 0dbfs) or change the docs to match the > behavior (in the presence of software mixing the clipping happens at > the hardware limit of the audio device, regardless of software mixer > settings - meaning that no matter the level you set on your > computer's software volume knob csound is capable of producing full > intensity output from the device). Note that in the latter case (the > current behavior) the amplitude at which samples will be clipped is > not csound's 0dbfs value. > > Hi Justin, > > OK I see. But to me that's as unlikely a scenario as someone > accidentally putting their finger in the electrical socket! But let me > do some testing, I use a software mixer (RMEs total mix) and have never > experienced anything like this, which make me wonder if the mixer > doesn't have a mechanism of truncating the input signal at 0dB. > > P ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2013-05-27 22:41
From	Pete Goodeve
Subject	Re: [Cs-dev] 0dbfs and floating output
Attachments	None