Nabble - Csound - Dev

Re: Truncation in Csound5

2008-10-12T03:21:33Z

We used to have a dither-on-output option in csound4 -- not a good one
i might add -- but in the change to Csound5 with libsndfile this
operation was deferred to the library code; we call the options to
switch it on. It has now been confirmed that this code is not
implemented, so we have the choice of resurrecting the cs4 code,
waiting for Erik's free time(TM), or writing it ourselves and offering
to libsndfile.
==John ffitch

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

liblo and mingw

2008-10-11T23:30:11Z

Hi All,

I tried to get liblo compiled on windows with MinGW and it took a
while. I managed to get it done using the following:

./configure LIBS=-lws2_32 CFLAGS="-DWIN32 -D_WIN32_WINNT=0x0501"

and commenting out gai_strerrorA in src/server.c. Most of this info
came from the cross-compile info for liblo on the CLAM site:

http://clam.iua.upf.edu/wikis/clam/index.php/Devel/Windows_MinGW_cross_compile

This got liblo-0.24 compiled here (0.25 failed, but I just went with
0.24). Just thought I'd mention this in case anyone runs into this.

Thanks!
steven

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Truncation in Csound5

2008-10-11T19:49:49Z

Boy! This is starting to get interesting now!

Michael Gogins wrote:

-- Do not render to any kind of integer soundfile, not even 24 bit. Render to float soundfiles. This also means do not dither.

-- If you must render to an integer format, dither in the final float to integer conversion step. If Csound's dither doesn't work, use an editor that has it.

The basic principle is: always use the highest-precision format that you possibly can (float, 88200 or 96000 Hz at a minimum) at every stage of rendering. If the target is a lower precision, put off converting to the lower precision until the very last step.

This is entirely consistent with the Bob Katz approach, and indeed is partly informed by it.

Regards,
Mike

Quite true, every word of it.

Regarding "If Csound's dither doesn't work, use an editor that has it.", on this I agree too, IF conversion to integer is required.

But additionally, I'd like to fix and improve the quality of dithering available in Csound, since I see in it the possibility of far better dither options than are available in most software and hardware you can get for under 5 figures. And, yes, I use the word in the plural, since I don't find one type of dither is adequate for ALL circumstances. POWr3 is extremely good, but it doesn't fit everything.

Richard Dobson wrote:

It has nothing to do with sample rates, but to with output sample format
  (floats, 24bit etc)  and thus could not be implemented as an opcode
(indeed would be meaningless as an opcode); it has to be part of the
output subsystem, whether writing to a soundcard (or other streaming
graph, when Csound is running as a plugin; but we would expect that to
be in floats  anyway) or to disk, and controlled at host or api level.
Portaudio, for example, has its own api for managing dither.

The only opcode I can imagine  would be some sort of "quantize" opcode
(e.g. for deliberate "grunging" of a sound), with dithering incorporated
as a parameter, applied (by default) to the lowest quantization  level.
I am so out of touch with Csound opcodes these days that perhaps there
already is such a thing?

Richard Dobson

Fons Adriaensen wrote:

I agree, the right place to do dithering is in the audio output
interface (either to HW or to file). It should be of no concern
to Csound itself.

There may be a good reason for what you both say here, that's plainly obvious to one and all--but my experience with the fine details of the workings of Csound is no where near where you guys are at.

Now, that said, my thoughts are these:

If Csound is running with streaming output, it would be better to upgrade the signal chain than dither Csound. And if it's running as a plug-in, then it's part of another program that quite likely has its own dither anyway, and you certainly wouldn't "double-dither"...that's a no-no. Also, if it's a plug-in that's part of a larger mix, then dither isn't called for until the mix is done, the polishing is complete and it's ready for CD or DVD.

There's another reason I lean toward Csound code (totally aside from being more familiar with it...):

Dither must be both random and UN-correlated= it CANNOT be correlated with either the signal NOR itself from one channel to another. In a stereo recording if the same dither is applied to both channels it will collapse the separation (along with the ambience that was being "salvaged" by dithering). Poor dither can be worse than no dither, as the last example would have lost the ambience and only had added noise.

The rand opcode can be easily configured with a different seed for each instance. I have tested it using a correlation meter= zero correlation. Placing it at the end of the orc in the csd file seems to work. But, feel free to point out anything I'm missing. This is still in the design stages.

And Csound can handle up to 16 channels of audio, which would have to addressed in this manner so as not to degrade the result. I'm sure this COULD be done internally in the audio output interface, but, aside from being a LOT of work on the internals of Csound (IMHO), it's also a lot to have going on that's "hard-wired" into Csound for a function that will get, at best 5% use (or less). And "changing or refining the dither algorithms" would be a real bitch as well.

But I well may be overlooking something quite obvious. Wouldn't be the first time....

All the Best,

Jim Bates

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Truncation in Csound5

2008-10-11T14:43:06Z

On Sat, Oct 11, 2008 at 10:23:03PM +0100, Richard Dobson wrote:

> It has nothing to do with sample rates, but to with output sample format
> (floats, 24bit etc) and thus could not be implemented as an opcode
> (indeed would be meaningless as an opcode); it has to be part of the
> output subsystem, whether writing to a soundcard (or other streaming
> graph, when Csound is running as a plugin; but we would expect that to
> be in floats anyway) or to disk, and controlled at host or api level.
> Portaudio, for example, has its own api for managing dither.

As does Jack when running under Linux or OSX.

I agree, the right place to do dithering is in the audio output
interface (either to HW or to file). It should be of no concern
to Csound itself.

Ciao,

--
FA

Follie! Follie! Delirio vano e' questo!

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Truncation in Csound5

2008-10-11T14:41:20Z

Richard Dobson wrote:

> but to with output sample format
> (floats, 24bit etc) and thus could not be implemented as an opcode
> (indeed would be meaningless as an opcode); it has to be part of the
> output subsystem, whether writing to a soundcard (or other streaming
> graph, when Csound is running as a plugin; but we would expect that to
> be in floats anyway) or to disk, and controlled at host or api level.
> Portaudio, for example, has its own api for managing dither.

Thats why one of the obvious places for it is in libsndfile because
at least for file output, thats is where the final conversion takes
place.

My plans for libsndfile were make dither an option that could be
switched on and off and even when switch on, to do it only when
the conversion required it.

Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Two hands working can do more than a thousand clasped in prayer."
-- anonymous

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Truncation in Csound5

2008-10-11T14:23:03Z

Jim Bates wrote:
..
> I don't think that dither should be put "under the hood" in
> Csound. It needs to be (ideally) in opcode format, so it could be
> called ONLY when converting work to lower sample rates, and
> even then only 'one shot'.
>

It has nothing to do with sample rates, but to with output sample format
(floats, 24bit etc) and thus could not be implemented as an opcode
(indeed would be meaningless as an opcode); it has to be part of the
output subsystem, whether writing to a soundcard (or other streaming
graph, when Csound is running as a plugin; but we would expect that to
be in floats anyway) or to disk, and controlled at host or api level.
Portaudio, for example, has its own api for managing dither.

The only opcode I can imagine would be some sort of "quantize" opcode
(e.g. for deliberate "grunging" of a sound), with dithering incorporated
as a parameter, applied (by default) to the lowest quantization level.
I am so out of touch with Csound opcodes these days that perhaps there
already is such a thing?

Richard Dobson

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Truncation in Csound5

2008-10-11T13:53:17Z

Just a side note, wanted to say thanks to everyone who contributed to
this thread; I learned quite a bit!

On Sat, Oct 11, 2008 at 11:04 AM, Jim Bates <jabates@...> wrote:

> Thank you all for your posts! The issue is resolved.
>
>
> Fons Adriaensen wrote:
>
>> You need dither when converting to an integer format,
>> in particular anything less than say 20 bits.
>> The procedure to do this when starting from floats is
>> exactly the same as when you start from a higher precision
>> integer format. You add noise then convert to integer.
>> Except in some rather special cases, the amplitude of
>> the noise depends on the 'step size' of the output format
>> only - this is why the procedure is essentially the same
>> for FP->16bit as for 24bit->16bit. The noise added
>> should have a triangular distribution between -1 and +1
>> times the output step size.
>
>
> Richard Dobson wrote:
>
>> People can practise this radical worldview by setting 0dbfs=1 in all
>> their orc files, rather than the historical but otherwise pointless
>> and
>> irrelevant 32768!
>
> Thank you for persisting in getting your point across Fons. It
> finally sank in, and along with Richard's point, the "dithering of
> floats to ints" is fully clear. So, thank you!
>
> I don't think that dither should be put "under the hood" in
> Csound. It needs to be (ideally) in opcode format, so it could be
> called ONLY when converting work to lower sample rates, and
> even then only 'one shot'.
>
> Richard--
> I'm writing Csound code for various dither algorithms. Would you
> be willing and able to re-write the code as an opcode or family
> of opcodes?
>
> All the Best,
> Jim Bates
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

Re: Truncation in Csound5

2008-10-11T11:04:47Z

Thank you all for your posts! The issue is resolved.

Fons Adriaensen wrote:

> You need dither when converting to an integer format,
> in particular anything less than say 20 bits.
> The procedure to do this when starting from floats is
> exactly the same as when you start from a higher precision
> integer format. You add noise then convert to integer.
> Except in some rather special cases, the amplitude of
> the noise depends on the 'step size' of the output format
> only - this is why the procedure is essentially the same
> for FP->16bit as for 24bit->16bit. The noise added
> should have a triangular distribution between -1 and +1
> times the output step size.

Richard Dobson wrote:

> People can practise this radical worldview by setting 0dbfs=1 in all
> their orc files, rather than the historical but otherwise pointless
> and
> irrelevant 32768!

Thank you for persisting in getting your point across Fons. It
finally sank in, and along with Richard's point, the "dithering of
floats to ints" is fully clear. So, thank you!

I don't think that dither should be put "under the hood" in
Csound. It needs to be (ideally) in opcode format, so it could be
called ONLY when converting work to lower sample rates, and
even then only 'one shot'.

Richard--
I'm writing Csound code for various dither algorithms. Would you
be willing and able to re-write the code as an opcode or family
of opcodes?

All the Best,
Jim Bates

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Truncation in Csound5

2008-10-11T10:34:45Z

I've been generally following Mike's advice by rendering to 96K/32, then
down-converting as necessary to 44.1K/16 with r8brain[1], which is free,
though not open source. Seems to do a very decent job, and it included
dithering.

- Dave

[1] http://www.voxengo.com/product/r8brain/

Michael Gogins wrote:

> My thoughts on this can be found in "A Csound Tutorial," the final section on audio quality. This is in the Windows installers for Csound and can be found on the SourceForge public page for Csound. In addition to my comments there:
>
> -- Do not render to any kind of integer soundfile, not even 24 bit. Render to float soundfiles. This also means do not dither.
>
> -- If you must render to an integer format, dither in the final float to integer conversion step. If Csound's dither doesn't work, use an editor that has it.
>
> The basic principle is: always use the highest-precision format that you possibly can (float, 88200 or 96000 Hz at a minimum) at every stage of rendering. If the target is a lower precision, put off converting to the lower precision until the very last step.
>
> This is entirely consistent with the Bob Katz approach, and indeed is partly informed by it.
>
> Regards,
> Mike

Re: Truncation in Csound5

2008-10-11T06:18:30Z

24 bits is not floating point, it is integer. So this is not at odds with Katz.

Regards,
Mike

-----Original Message-----

>From: Jim Bates <jabates@...>
>Sent: Oct 10, 2008 8:54 PM
>To: csound-devel@...
>Subject: [Cs-dev] Truncation in Csound5
>
>My earlier post regarding the dither problem in Csound5 was started
>before I found out there is no dither currently in Csound5. While it
>has been implied that dither is not needed on a floating point
>system, that viewpoint is at odds with the following from the
>renowned mastering engineer Bob Katz:
>
>"But one programming mistake, or a few cost-saving shortcuts, can
>ruin ether fixed or floating point work, especially if shortcuts are
>taken at the most critical time, when the final output number is
>converted to fixed point 24 bit at the end. If those numbers are not
>converted (and properly dithered to 24 bits) at that time, then the
>sound of the entire system can be compromised."
> Bob Katz "Fixed versus Floating Point Notation" (an answer to a
>question on his Audio FAQ)
>
>"When feeding processors, DAWs or digital mixers to your recording
>unit, dither the output of the processor to a 24-bit word. Dithering
>always sounds better than truncation without dither."
> Bob Katz' article "Dither" Full article at: http://www.digido.com
>
>So the real problem is more accurately a truncation problem.
>
>As the contention is about dithering floating point, I e-mailed Bob
>Katz with the following question:
>
>Do you know of any current (or past) algorithm for dithering floating
>point audio files?
>
>Here is his reply:
>
>
>Floating point is not the ideal medium for dithering as you don't
>know where the reference level is, it's "floating" :-). Some people
>argue (probably correctly) that dithering makes no sense with
>floating point. So most algorithm designers convert to fixed point
>and then dither. Does that answer your question?
>
>
>Best wishes,
>
>Bob
>--
>Bob Katz 407-831-0233 DIGITAL DOMAIN | "There are two kinds of fools,
>Recording, Mastering, Manufacturing | One says-this is old and
>therefore good.
>Informative **CD MASTERING WEBSITE** | The other says-this is new and
>therefore
>http://www.digido.com | better."
>
>No trees were killed in the sending of this message. However a large
>number
>of electrons were terribly inconvenienced.
>
>
>Another reference regarding that confirms this can be found here:
>http://www.cadenzarecording.com/images/FloatingDither.pdf
>
>
>This is as clear as I know how to put it.
>
>I would appreciate some feedback on this from those who actually
>develop Csound, like Anthony Kozar, Michael Goggins, Andres Cabrera,
>Steven Yi, Victor Lazzarini, John ffitch, etc.
>
>All the Best,
>Jim Bates
>

Re: Truncation in Csound5

2008-10-11T06:17:24Z

My thoughts on this can be found in "A Csound Tutorial," the final section on audio quality. This is in the Windows installers for Csound and can be found on the SourceForge public page for Csound. In addition to my comments there:

-- Do not render to any kind of integer soundfile, not even 24 bit. Render to float soundfiles. This also means do not dither.

-- If you must render to an integer format, dither in the final float to integer conversion step. If Csound's dither doesn't work, use an editor that has it.

The basic principle is: always use the highest-precision format that you possibly can (float, 88200 or 96000 Hz at a minimum) at every stage of rendering. If the target is a lower precision, put off converting to the lower precision until the very last step.

This is entirely consistent with the Bob Katz approach, and indeed is partly informed by it.

Regards,
Mike

-----Original Message-----

Re: Truncation in Csound5

2008-10-11T03:29:36Z

Richard Dobson wrote:

> The best dithering we can reasonably
> expect in Csound is plain TPDF (triangular); which is actually pretty
> good.

I do mean to (optionally) add the ability to dither appropriate
conversions to libsndfile at some time. Unfortunately, my spare
time is rather limited.

> We have no excuses with regard to file sizes these
> days, except for high channel counts and high sample rates, and even
> WAVE itself can support 64bit doubles (I am pretty certain libsndfile
> supports that - Eric?).

Yes, libsndfile supports writing IEEE double floats to WAV, AIFF, AU
and a number of other formats.

Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Indeed, I am impressed that Google runs an 8,000 node Linux
cluster, 5 data centers, an extensive network, and a rapidly
evolving application all with a staff of 12."
-- http://research.microsoft.com/~gray/papers/FAAMs_HPTS.doc

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Truncation in Csound5

2008-10-11T02:38:45Z

On Fri, Oct 10, 2008 at 08:54:31PM -0400, Jim Bates wrote:

> My earlier post regarding the dither problem in Csound5 was started before
> I found out there is no dither currently in Csound5. While it has been
> implied that dither is not needed on a floating point system, that
> viewpoint is at odds with the following from the renowned mastering
> engineer Bob Katz:
>
> "But one programming mistake, or a few cost-saving shortcuts, can ruin
> ether fixed or floating point work, especially if shortcuts are taken at
> the most critical time, when the final output number is converted to fixed
> point 24 bit at the end. If those numbers are not converted (and properly
> dithered to 24 bits) at that time, then the sound of the entire system can
> be compromised."
> ...
> Floating point is not the ideal medium for dithering as you don't know
> where the reference level is, it's "floating" :-). Some people argue
> (probably correctly) that dithering makes no sense with floating point. So
> most algorithm designers convert to fixed point and then dither. Does that
> answer your question?

This is correct. There is no need to add dither inside algorithms
(e.g. filters, mixers, etc..) that operate entirely in FP, and
it would be difficult to do since, as Bob says, there is no
reference level and the granularity of the output signal is not
fixed.

You need dither when converting to an integer format,
in particular anything less than say 20 bits.
The procedure to do this when starting from floats is
exactly the same as when you start from a higher precision
integer format. You add noise then convert to integer.
Except in some rather special cases, the amplitude of
the noise depends on the 'step size' of the output format
only - this is why the procedure is essentially the same
for FP->16bit as for 24bit->16bit. The noise added
should have a triangular distribution between -1 and +1
times the output step size.

Ciao,

--
FA

Follie! Follie! Delirio vano e' questo!

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Truncation in Csound5

2008-10-11T01:49:43Z

Erik de Castro Lopo wrote:
..

> For 24 bit audio the audio samples range from -8388608 to 8388607
> and the dither that is added (before truncation) is at most about
> -2.0 to 2.0 (I've been generous here) with reference to the range
> -8388608 to 8388607.
>
> That means that the level of the dither is
>
> 20 * log10 (2 / 8388607)
>
> which is -132dB below the reference level. I repeat, there is no
> digital-to-analogue converter on the market today that comes
> anywhere near this in signal to noise ratio.
>

As an example I have here, my M-Audio Firewire 410 cites a dynamic
range of 108dB; i.e. the quiescent noise is significantly above what
would be the 24bit dither level. Top-level systems may manage 120dB, and
top-end mic preamps may even cite a range of 130dB - still above the
theoretical 24bit dither level. To improve on that would need
liquid-cooled circuitry (and probably liquid-cooled ears and
loudspeakers too).

A simple answer to all this is to use f/p soundfiles ~always~, and
reduce to 24bit (or 16bit) only at the very end, as part of the final
mastering stage (or output to speakers). Note that normalized 32bit f/p
actually gives you an equivalent 25bit range (the format provides what
is referred to as a "hidden bit"). The best dithering we can reasonably
expect in Csound is plain TPDF (triangular); which is actually pretty
good. Commercial mastering tools will offer more sophisticated (and
mostly proprietary) noise-shaped dither. Until such time as users
seriously expect to send the output of perf directly to CD manufacture,
i.e. do all final mastering in Csound itself, all we really need is
some token dither for direct audio rendering. Windows already adds
tpdf dither to audio streamed through the kernel mixer, and I think OS X
CoreAudio does something very similar. SO if dither is added to Csound,
it must be possibel to turn it off. There is of course absolutely no
reason to reduce to 16bit for rendering, these days, unless you are
still using SoundBlasters, in which case of course the analog dynamic
range still comes to your rescue.

In short, you may need to deliver in 24bits (or 16 bits for the
venerable CD etc), but work in progress should always be kept as at
least 32bit f/p. We have no excuses with regard to file sizes these
days, except for high channel counts and high sample rates, and even
WAVE itself can support 64bit doubles (I am pretty certain libsndfile
supports that - Eric?).

People can practise this radical worldview by setting 0dbfs=1 in all
their orc files, rather than the historical but otherwise pointless and
irrelevant 32768!

Richard Dobson

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Truncation in Csound5

2008-10-10T20:30:30Z

Jim Bates wrote:

> My earlier post regarding the dither problem in Csound5 was started
> before I found out there is no dither currently in Csound5. While it
> has been implied that dither is not needed on a floating point
> system,

If the audio stays in floating point that is 100% correcct.

The only time it *may* be worthwhile dithering is when converting from
floating point to integer (8, 16 or 24 bit integer) formats, or when
converting from a higher bitwidth integer to a smaller bit width integer.

> that viewpoint is at odds with the following from the
> renowned mastering engineer Bob Katz:
>
> "But one programming mistake, or a few cost-saving shortcuts, can
> ruin ether fixed or floating point work, especially if shortcuts are
> taken at the most critical time, when the final output number is
> converted to fixed point 24 bit at the end. If those numbers are not
> converted (and properly dithered to 24 bits) at that time, then the
> sound of the entire system can be compromised."

Saying that when converting from float to 24 bit integer PCM without
dither "then the sound of the entire system can be compromised." is
*vastly* overstating the case.

For 24 bit audio the audio samples range from -8388608 to 8388607
and the dither that is added (before truncation) is at most about
-2.0 to 2.0 (I've been generous here) with reference to the range
-8388608 to 8388607.

That means that the level of the dither is

20 * log10 (2 / 8388607)

which is -132dB below the reference level. I repeat, there is no
digital-to-analogue converter on the market today that comes
anywhere near this in signal to noise ratio.

Remeber what the dither is there for. Its added noise which masks
low level artifacts that are the result of truncation. When the
dither is at -132dB, the stuff that it is masking is below that.

If you look at this:

http://en.wikipedia.org/wiki/Sound_pressure#Examples_of_sound_pressure_and_sound_pressure_levels

with 0db being the threshold of hearing, 120dB is where you start
getting hearing damager and 130dB is the threshold of pain.

> As the contention is about dithering floating point, I e-mailed Bob
> Katz with the following question:
>
> Do you know of any current (or past) algorithm for dithering floating
> point audio files?
>
> Here is his reply:
>
> Floating point is not the ideal medium for dithering as you don't
> know where the reference level is, it's "floating" :-). Some people
> argue (probably correctly) that dithering makes no sense with
> floating point. So most algorithm designers convert to fixed point
> and then dither. Does that answer your question?

Thats a totally appropriate answer to someone who may not know
how numbers are represented in floating point, but it is far
from a definitive answer.

Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"C++ is an atrocity, the bletcherous scab of the computing world,
responsible for more buffer overflows, more security breaches,
more blue screens of death, more mysterious failures than any
other computer language in the history of the planet Earth."
-- Eric Lee Green

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Truncation in Csound5

2008-10-10T17:54:31Z

My earlier post regarding the dither problem in Csound5 was started before I found out there is no dither currently in Csound5. While it has been implied that dither is not needed on a floating point system, that viewpoint is at odds with the following from the renowned mastering engineer Bob Katz:

"But one programming mistake, or a few cost-saving shortcuts, can ruin ether fixed or floating point work, especially if shortcuts are taken at the most critical time, when the final output number is converted to fixed point 24 bit at the end. If those numbers are not converted (and properly dithered to 24 bits) at that time, then the sound of the entire system can be compromised."

Bob Katz "Fixed versus Floating Point Notation" (an answer to a question on his Audio FAQ)

"When feeding processors, DAWs or digital mixers to your recording unit, dither the output of the processor to a 24-bit word. Dithering always sounds better than truncation without dither."

Bob Katz' article "Dither" Full article at: http://www.digido.com

So the real problem is more accurately a truncation problem.

As the contention is about dithering floating point, I e-mailed Bob Katz with the following question:

Do you know of any current (or past) algorithm for dithering floating point audio files?

Here is his reply:

Floating point is not the ideal medium for dithering as you don't know where the reference level is, it's "floating" :-). Some people argue (probably correctly) that dithering makes no sense with floating point. So most algorithm designers convert to fixed point and then dither. Does that answer your question?

Best wishes,

Bob

Bob Katz 407-831-0233 DIGITAL DOMAIN | "There are two kinds of fools,

Recording, Mastering, Manufacturing | One says-this is old and therefore good.

Informative **CD MASTERING WEBSITE** | The other says-this is new and therefore

http://www.digido.com | better."

No trees were killed in the sending of this message. However a large number

of electrons were terribly inconvenienced.

Another reference regarding that confirms this can be found here: http://www.cadenzarecording.com/images/FloatingDither.pdf

This is as clear as I know how to put it.

I would appreciate some feedback on this from those who actually develop Csound, like Anthony Kozar, Michael Goggins, Andres Cabrera, Steven Yi, Victor Lazzarini, John ffitch, etc.

All the Best,

Jim Bates

Re: Messages to callback in C API and C++ API

2008-10-09T17:37:53Z

Sorry, silly mistake, I put the setMessageCallback after the call to compile...
Everything's OK.

Cheers,
Andrés

On Tue, Oct 7, 2008 at 9:54 AM, Andres Cabrera <mantaraya36@...> wrote:

> Hi all,
>
> I've noticed the behavior of csound messages sent to the callback is
> different in the C and C++ APIs. Using the C++ API, all messages are
> sent to the callback, but I've just changed to using the standard C
> API and only some of the messages are routed to the message callback
> function. Messages like the csound version and error messages are sent
> to stderr. What can I do to make the C API send all messages to the
> callback function?
>
> Cheers,
> Andrés
>

--

Andrés

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Glitch-free csound

2008-10-09T07:30:04Z

I have a version of Csound5 that does Russell's example without
glitches. I have changed things to count in samples rather than in
seconds, and so keeps things in integers. It does not fix the same
problems in beatmode and I probably need to check to see what else it
breaks.

May also be a little slower, but that could be minor and even
optimised out.

Back to testing

==John ffitch

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Dither Problem in Csound5

2008-10-08T15:39:03Z

A very good reference on dithering issues and the differences in
dithering for ints and floats can be found here:

http://www.cadenzarecording.com/images/FloatingDither.pdf

All the Best,
Jim Bates

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Csound-devel Digest, Vol 30, Issue 13

2008-10-08T14:23:17Z

On Wed, Oct 08, 2008 at 05:10:40PM -0400, Jim Bates wrote:

> Let me rephrase my other point on the matter, which is this:
>
> After Csound has run its numbers in doubles, it is downsampled to float.

As Eric has already pointed out, this is not 'downsampling'.
It's conversion (in this case) or (re)quantisation if you
convert to int or fixed point.

> BUT, since Csound's output is floating point, trying to
> dither it while downsampling to 24-Bit or 16-Bit DOESN'T
> work, even if the dither function IS working.

That means you implemented it wrong. It *does* work.
There should be no problem at all with the original
being float or double rather than int. The basic
approach is to add noise, then convert to lower
precision.

> I know--
> --I've tried it with POWr3 dither and other dithers using
> an external application.

You, or the external application, must have done something
wrong.

Ciao,

--
FA

Follie! Follie! Delirio vano e' questo!

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Csound-devel Digest, Vol 30, Issue 13

2008-10-08T14:10:40Z

Sorry Jim, but none of that makes any sense whatsoever.

Downsampling is the process of converting from a higher sampling

rate to a lower sampling rate and has nothing to do with the way

the individual samples are represented (int, float double etc).

What you are talking about it changing the bit width (and hence

precision) of the samples which is correctly called re-quantization.

Dither is added when re-quantizing samples from a higher bit

width to a lower bit width. Its purpose is to hide audilble

correlated artifacts arising from the bit width reduction.

When those correlated artifacts are not audible, there is no

reason to add dither. For instance when converting floating

point data to 24 bit PCM (and using the full 24 bits) there

is no point in adding dither because the dynamic range of

24 bit audio is about 144dB and any correlated artifacts would

be 144dB below the loudest part and hence quieter than the

best playback system money can by (I think the best available

D-A converters have a signal to noise ratio of about 125dB).

Since floats have more than 24 bits of dynamic range, there

is no good reason to add dither when converting from double

to float.

For more on dither, see the wikipedia article:

http://en.wikipedia.org/wiki/Dither

Erik

--

I got it Erik. Thank you for your response --regarding the internal downsampling

of doubles to floats---your point on the matter is valid and well taken.

Let me rephrase my other point on the matter, which is this:

After Csound has run its numbers in doubles, it is downsampled to float.

BUT, since Csound's output is floating point, trying to dither it while downsampling

to 24-Bit or 16-Bit DOESN'T work, even if the dither function IS working. I know--

--I've tried it with POWr3 dither and other dithers using an external application.

No effect whatsoever.

That's the reason I was looking at re-quantization to a format that COULD be

effectively dithered with existing dithering algorithms.

Perhaps there is a better way of solving it.

But I don't see it as trivial issue.

All the Best,

JIm Bates

Re: Dither Problem in Csound5

2008-10-08T13:33:10Z

On Thu, Oct 09, 2008 at 06:50:34AM +1100, Erik de Castro Lopo wrote:

> When those correlated artifacts are not audible, there is no
> reason to add dither. For instance when converting floating
> point data to 24 bit PCM (and using the full 24 bits) there
> is no point in adding dither because the dynamic range of
> 24 bit audio is about 144dB and any correlated artifacts would
> be 144dB below the loudest part and hence quieter than the
> best playback system money can by (I think the best available
> D-A converters have a signal to noise ratio of about 125dB).

I'd say that's 99.9% correct.

When you convert to 24 bit, either for a DA convertor
or for writing a file, and your signal contains anything
that was recorded from an analog source, then it very
probably has already enough noise in it to make any
dithering pointless.

For synthesised signals this could be different. In
the case of a DA converter, any correlated artifacts
will be masked by the analog noise, but they are still
there - you *can* measure them. Same for a file, where
they are not even masked because there is no analog
noise.

To *remove* rather than mask them, you have to add
noise *before* the quantisation. If you have 24 bits
anyway, this noise can be so low that you will never
hear it - but it has to be added if your signal is
otherwise noise-free.

Ciao,

--
FA

Follie! Follie! Delirio vano e' questo!

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Dither Problem in Csound5

2008-10-08T12:55:18Z

(Okay, I'll just note that I'm glad Erik and Fons and everyone else is
here on this list! =) )

On Wed, Oct 8, 2008 at 12:50 PM, Erik de Castro Lopo
<mle+la@...> wrote:

> Jim Bates wrote:
>
>> As far as I know there is (currently) no workable algorithm for
>> floating point dither; and dither designed for ints
>> does not work on floats. So one way for handling this would be
>> converting the 64-Bit doubles to 80-Bit ints
>> and dithering the result, using a conventional rectangular dither,
>> prior to downsampling to 40-Bit int, which can
>> then be converted to 32-Bit float, or to a lower Bit-depth.
>> That would be the first step in handling the internal (doubles to
>> floats) dither problem. It would also give
>> a 40 bit int that could be easily downsampled and dithered to 32, 24
>> or 16 Bits. 32-Bit floats don't dither any
>> better than 64-Bit doubles do.
>
> Sorry Jim, but none of that makes any sense whatsoever.
>
> Downsampling is the process of converting from a higher sampling
> rate to a lower sampling rate and has nothing to do with the way
> the individual samples are represented (int, float double etc).
>
> What you are talking about it changing the bit width (and hence
> precision) of the samples which is correctly called re-quantization.
>
> Dither is added when re-quantizing samples from a higher bit
> width to a lower bit width. Its purpose is to hide audilble
> correlated artifacts arising from the bit width reduction.
>
> When those correlated artifacts are not audible, there is no
> reason to add dither. For instance when converting floating
> point data to 24 bit PCM (and using the full 24 bits) there
> is no point in adding dither because the dynamic range of
> 24 bit audio is about 144dB and any correlated artifacts would
> be 144dB below the loudest part and hence quieter than the
> best playback system money can by (I think the best available
> D-A converters have a signal to noise ratio of about 125dB).
>
> Since floats have more than 24 bits of dynamic range, there
> is no good reason to add dither when converting from double
> to float.
>
> For more on dither, see the wikipedia article:
>
> http://en.wikipedia.org/wiki/Dither
>
> Erik
> --
> -----------------------------------------------------------------
> Erik de Castro Lopo
> -----------------------------------------------------------------
> "Well behaved women rarely make history." -- Dorothy Parker
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

Re: Dither Problem in Csound5

2008-10-08T12:50:34Z

Jim Bates wrote:

> As far as I know there is (currently) no workable algorithm for
> floating point dither; and dither designed for ints
> does not work on floats. So one way for handling this would be
> converting the 64-Bit doubles to 80-Bit ints
> and dithering the result, using a conventional rectangular dither,
> prior to downsampling to 40-Bit int, which can
> then be converted to 32-Bit float, or to a lower Bit-depth.
> That would be the first step in handling the internal (doubles to
> floats) dither problem. It would also give
> a 40 bit int that could be easily downsampled and dithered to 32, 24
> or 16 Bits. 32-Bit floats don't dither any
> better than 64-Bit doubles do.

Sorry Jim, but none of that makes any sense whatsoever.

Downsampling is the process of converting from a higher sampling
rate to a lower sampling rate and has nothing to do with the way
the individual samples are represented (int, float double etc).

What you are talking about it changing the bit width (and hence
precision) of the samples which is correctly called re-quantization.

Dither is added when re-quantizing samples from a higher bit
width to a lower bit width. Its purpose is to hide audilble
correlated artifacts arising from the bit width reduction.

When those correlated artifacts are not audible, there is no
reason to add dither. For instance when converting floating
point data to 24 bit PCM (and using the full 24 bits) there
is no point in adding dither because the dynamic range of
24 bit audio is about 144dB and any correlated artifacts would
be 144dB below the loudest part and hence quieter than the
best playback system money can by (I think the best available
D-A converters have a signal to noise ratio of about 125dB).

Since floats have more than 24 bits of dynamic range, there
is no good reason to add dither when converting from double
to float.

For more on dither, see the wikipedia article:

http://en.wikipedia.org/wiki/Dither

Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Well behaved women rarely make history." -- Dorothy Parker

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

OSC problem

2008-10-08T12:23:20Z

Helllo all,

Ar you looking at this problem with OSC?
Thanks
jp

Looking at the OSC code, OSCinit does not have a deinit callback
(but OSClisten does). I never programmed liblo, but I expect
lo_server_thread_stop() needs to be called to free the port. I
don't think it is called.

John's your expert here, he should be able to answer this one.

Victor

----- Original Message ----- From: "victor" <Victor.Lazzarini@...>
To: <csound@...>
Sent: Tuesday, October 07, 2008 9:50 PM
Subject: [Csnd] Re: use of OSC with csound API

Looks like the opcode requires a deinit callback (a destructor), which
it doesn't have, to free the port. Or does it? Perhaps we should discuss
this in the
developer's list.

Victor
----- Original Message ----- From: "jean-pierre lemoine"
<lemoine.jp@...>
To: <csound@...>
Sent: Tuesday, October 07, 2008 8:11 PM
Subject: [Csnd] use of OSC with csound API

I am implemented OSC support in AVSynthesis. but I have a problem
with reusing the csound instance (windows platform, csound double)

I start a thread which executes in its loop
cs.Perform();
cs.Cleanup();
cs.Reset();

When I stop the csound execution from the main thread, csound stops,
and the cleanup , reset are done.
If I launch a new thread with the same csound instance, i get the
following error message and a trap
OSC server error 9904 in path (null): cannot find free port

The trap
#
# An unexpected error has been detected by Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x2fc75321, pid=2444,
tid=3524
#
# Java VM: Java HotSpot(TM) Client VM (10.0-b19 mixed mode, sharing
windows-x86)
# Problematic frame:
# C [lo.dll+0x5321]
#

It seems that the OSC resources are not released during cleanup and
reset. Do I need to do something specific?

In the csd I have
giOSChandle OSCinit 7770

and

instr 1
kreadOSC init 0
kosc OSClisten giOSChandle, "/AVS/layer1", "f", kreadOSC
if (kosc == 0) goto exl1
gkchLayer1 = kreadOSC
printk .1, gkchLayer1
exl1:
kosc OSClisten giOSChandle, "/AVS/layer2", "f", kreadOSC
if (kosc == 0) goto exl2
gkchLayer2 = kreadOSC
exl2:
kosc OSClisten giOSChandle, "/AVS/layer3", "f", kreadOSC
if (kosc == 0) goto exl3
gkchLayer3 = kreadOSC
exl3:
kosc OSClisten giOSChandle, "/AVS/layer4", "f", kreadOSC
if (kosc == 0) goto exl4
gkchLayer4 = kreadOSC
exl4:
kosc OSClisten giOSChandle, "/AVS/layer5", "f", kreadOSC
if (kosc == 0) goto exl5
gkchLayer5 = kreadOSC
exl5:
kosc OSClisten giOSChandle, "/AVS/layer6", "f", kreadOSC
if (kosc == 0) goto exl6
gkchLayer6 = kreadOSC
exl6:
kosc OSClisten giOSChandle, "/AVS/layer7", "f", kreadOSC
if (kosc == 0) goto exl7
gkchLayer7 = kreadOSC
exl7:
kosc OSClisten giOSChandle, "/AVS/layer8", "f", kreadOSC
if (kosc == 0) goto exl8
gkchLayer8 = kreadOSC
exl8:
endin

Thanks for any help

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel

Re: Dither Problem in Csound5

2008-10-08T11:27:30Z

On Wed, Oct 08, 2008 at 01:08:04PM -0400, Jim Bates wrote:

> As far as I know there is (currently) no workable algorithm for floating
> point dither;

There may well be a good reason for that -
AFAICS, it doesn't make any sense to do it.

Single precision floating is at least as good
as 24 bit linear, and the quantisation noise
for 24 bits is so low that you can forget about
it. If your concern is systematic errors that
can occur on simple periodic signals, just add
noise at -130dB below the nominal signal level
or so, and the errors will be randomised (turned
into noise which is still so low you will never
hear it).

> one way for handling this would be converting
> the 64-Bit doubles to 80-Bit ints and dithering
> the result, using a conventional rectangular
> dither, prior to downsampling to 40-Bit int,
> which can then be converted to 32-Bit float,

This would be a complete waste of time, first
for the reason mentioned above, and second
because this procedure doesn't do what you
think it does.

Ciao,

--
FA

Follie! Follie! Delirio vano e' questo!

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel