Csound Csound-dev Csound-tekno Search About

Re: Floats to Ints

Date1999-02-12 12:25
FromRichard Dobson
SubjectRe: Floats to Ints
Since this is a C-programming topic:

I agree: use method 1;

Division is usually much more expensive than multiplication, so you
would get better performance by multiplying by the constant 1/32767:
shorts to floats:
const float shortfac = (float) 1.0 / 32767.0;
	outfloat  = (float)inshort * shortfac;

going in the other direction obviously depends on whether the floatsams
are normalized ( within +- 1.0) or not.

It is a moot point whether one should scale right up to 32767 anyway - a
little bit of extra headroom would be good.

Ideally, when converting floats to shorts, which is a reduction in
resolution, you should dither the lowest bits with some form of noise
signal. But you should only do this if it is the last operation before
playing.

Note that the compiler cast from float to short (or double to int, etc)
can be surprisingly costly in processor cycles (especially with
Microsoft VC++, as they make a function call!); it is something to avoid
as much as possible! In this case an assembler routine can be a great
improvement, where cross-platform portability is not an issue.



Richard Dobson

Anders Andersson wrote:
> 
> Hello dear CSounders!
> 
> I'm writing a tool to convert float-samples to
> integers, as a newbie project while I'm learning
> C, but now I have a question about how to scale
> a stream of floats correctly to fit to the full
> integer range?
> 
> The problem is the assymetric integer-format,
> as the range is from -32768 -> 32767 (16-bit).
> 
> What method should I use when scaling?
> 
> 1. [output stream] = [stream of floats] * (32767/maxfloat)
> 
> 2. [output stream] = [stream of floats] * (32767.5/maxfloat)-0.5
> 
> The second version will have a slight offset, but the resolution
> will be better.. In this case I guess that the small offset
> won't affext the soundquality at all?
> 
> Yes, I know we are talking about *extremly* small
> values, that can't possibly be *heard* with even
> the best speakers/amplifiers/da-converters!!!
> But still! I'm a perfectionist!, and you should
> also be able to output 8-bit integers, and there
> may the difference be heard..
> 
> .--- -- -  -
> | Anders "Pipe/Nature" Andersson, pipe@algonet.se
> | Proud member of the Amiga community, Nature and Mensa Sweden.
> :

-- 
Test your DAW with my Soundcard Attrition Page!
http://wkweb5.cableinet.co.uk/rwd

Date1999-02-12 15:17
FromAnders Andersson
SubjectRe: Floats to Ints
>It is a moot point whether one should scale right up to 32767 anyway - a
>little bit of extra headroom would be good.

Why would that be good?
The point is that this should be the
last stage before burning to CD
(or encoding to MP3, whatever)
Wouldn't it be good to use ALL
bit's possible?
(No, I don't care if you are
 going to play it on some crappy
 soundblaster DA that can't handle
 the full range linear.. :D)


>Ideally, when converting floats to shorts, which is a reduction in
>resolution, you should dither the lowest bits with some form of noise
>signal. But you should only do this if it is the last operation before
>playing.

As a matter of fact it's suppose to be the last stage..
Why would I want to do this? Isn't that to discard the last bit?!

Hmm.. maybe one should do a "FS-dithering" on the sample..



>as much as possible! In this case an assembler routine can be a great
>improvement, where cross-platform portability is not an issue.

Well, I'm afraid it has to be 10000% ANSI-C.. =)
I've already written a program like this in 100% 68k-asm,
And that version is A BIT faster then my current C-version..
Wonder why! =)



.--- -- -  -
| Anders "Pipe/Nature" Andersson, pipe@algonet.se
| Proud member of the Amiga community, Nature and Mensa Sweden.
:



Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa09898;
          12 Feb 99 18:54 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by shaun.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10BNjD-0000vZ-00; Fri, 12 Feb 1999 18:54:15 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (SAA06982); Fri, 12 Feb 1999 18:51:09 GMT
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 12 Feb 1999 18:50:57 GMT
Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (SAA04645); Fri, 12 Feb 1999 18:50:56 GMT
Received: (qmail 25726 invoked from network); 12 Feb 1999 18:47:44 -0000
Received: from unknown (HELO cableinet.co.uk) (194.117.146.100)
  by jaguars with SMTP; 12 Feb 1999 18:47:44 -0000
Message-ID: <36C478F2.34777B2E@cableinet.co.uk>
Date: Fri, 12 Feb 1999 18:54:42 +0000
From: Richard Dobson 
Organization: Composers Desktop Project
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: CSound list 
Subject: Re: Floats to Ints
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

You would still be using all the bits; you don't fall to 15bits until
the amplitude has descended to +-16384. If the signal is definitely not
going to have any further treatment before being rendered, then
normalizing to 32767 may be OK. However, in the worst case your signal
may contain something like a square wave , which, if full-scale
peak-to-peak, is not 0dB, but at +3dB. 

A full-scale sinewave is at 0db(FS) peak (i.e voltage), but at -3dB RMS.
Music signals are more complex than pure sinewaves, and may exceed that
RMS power. I prefer to normalize to around -3dB peak (say, 24000), so
that there is less chance of the rms power exceeeding 0dB - and always
while working on sounds.  You simply don't have the soft headroom in
digital that you get with analogue tape! That full-scale square-wave, if
seen as band-limited, as it should be, actually has little ripples
beyond the main 'flat' part, so my little bit of headroom simply gives
that square wave a bit of extra space to wiggle in.

So I suppose I am using 15.5 bits.

In any case, I suppose we should all be working in 24bit ints or floats,
now, anyway! And, in fact, in my own playback code, if I am reading a
CDP floatsam file I can get the peak value from the header and if it is
above 1.0 I normalize to full-scale shorts for the soundcard, which
works very well - by definition no other process will be applied to the
sound. But for 'work-in-progress' sounds, I always aim for -3dB. Even
filters with nominally unity gain may actually wobble a little bit.

Yes, the dithering is 'the last stage', and should therefore be built
into the soundcard or dac. But often it isn't, so it has to be applied
to the sound before it is sent to the convertor. Which is why you have
dithering options in Cool Edit Pro, etc. 

Richard Dobson


Anders Andersson wrote:
> 
> >It is a moot point whether one should scale right up to 32767 anyway - a
> >little bit of extra headroom would be good.
> 
> Why would that be good?
> The point is that this should be the
> last stage before burning to CD
> (or encoding to MP3, whatever)
> Wouldn't it be good to use ALL
> bit's possible?
> (No, I don't care if you are
>  going to play it on some crappy
>  soundblaster DA that can't handle
>  the full range linear.. :D)
> 
> >Ideally, when converting floats to shorts, which is a reduction in
> >resolution, you should dither the lowest bits with some form of noise
> >signal. But you should only do this if it is the last operation before
> >playing.
> 
> As a matter of fact it's suppose to be the last stage..
> Why would I want to do this? Isn't that to discard the last bit?!
> 
> Hmm.. maybe one should do a "FS-dithering" on the sample..
> 


-- 
Test your DAW with my Soundcard Attrition Page!
http://wkweb5.cableinet.co.uk/rwd
CDP homepage: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm


Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10573;
          13 Feb 99 0:16 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10BSlN-0001RX-00; Sat, 13 Feb 1999 00:16:49 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (AAA11516); Sat, 13 Feb 1999 00:12:20 GMT
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 13 Feb 1999 00:12:07 GMT
Received: from titan.mad.servicom.es [194.106.0.133] by hermes via ESMTP (AAA00422); Sat, 13 Feb 1999 00:12:06 GMT
Received: from [62.81.84.59] by titan.mad.servicom.es
          (Post.Office MTA v3.1.2 release (PO203-101c)
          ID# 158-43936U25000L25000S0) with ESMTP id AAB12975
          for ; Sat, 13 Feb 1999 01:12:09 +0100
X-Mailer: Microsoft Outlook Express for Macintosh - 4.01 (295) 
Date: Sat, 13 Feb 1999 00:02:32 +0000
Subject: Dumb question
From: Javier Ruiz 
To: Csound Lista 
Mime-version: 1.0
X-Priority: 3
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Message-ID: <19990213001206.AAB12975@[62.81.84.59]>
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Dear all,
If I am not wrong, several opcodes, like oscil, ask the amplitude parameter
to be in the 0-32767(32768?) range. 
And I wonder if this is assuming that the final audio will be in 16 bits
integer.
Is this a souvenir from a recent past?
Maybe all these opcodes should ask for a normalized -1..1 value.

Is this a stupid matter or is just the fact that I live midway between New
York and Berlin in the Atlantic Ocean on a tiny island with absolutely no
computer music books in its libraries?

Gracias por vuestro saber.



Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10760;
          13 Feb 99 2:10 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10BUXJ-0001WD-00; Sat, 13 Feb 1999 02:10:25 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (CAA11003); Sat, 13 Feb 1999 02:07:11 GMT
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 13 Feb 1999 02:06:58 GMT
Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (CAA12122); Sat, 13 Feb 1999 02:06:57 GMT
Received: (qmail 15125 invoked from network); 13 Feb 1999 02:03:46 -0000
Received: from unknown (HELO cableinet.co.uk) (194.117.146.156)
  by jaguars with SMTP; 13 Feb 1999 02:03:46 -0000
Message-ID: <36C4DF24.515328C9@cableinet.co.uk>
Date: Sat, 13 Feb 1999 02:10:44 +0000
From: Richard Dobson 
Organization: Composers Desktop Project
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: csound@maths.ex.ac.uk
Subject: Re: Dumb question
References: <19990213001206.AAB12975@[62.81.84.59]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

I didn't think the code actally limited the value to 32768; internally
they are all floats, so in principle is should be possible to run oscil
at a 24bit int range, for example. These opcodes are so generic (not
confined to audio signals - could be trajectories in some fantastical
fractal space), so any limiting of values would cause somebody a
problem!

I don't think there are any 'stupid matters' in Csound; there are
questions some people have answers to, and some that people don't. Where
you live sounds like a very nice place.

Richard dobson

Javier Ruiz wrote:
> 
> Dear all,
> If I am not wrong, several opcodes, like oscil, ask the amplitude parameter
> to be in the 0-32767(32768?) range.
> And I wonder if this is assuming that the final audio will be in 16 bits
> integer.
> Is this a souvenir from a recent past?
> Maybe all these opcodes should ask for a normalized -1..1 value.
> 
> Is this a stupid matter or is just the fact that I live midway between New
> York and Berlin in the Atlantic Ocean on a tiny island with absolutely no
> computer music books in its libraries?
> 
> Gracias por vuestro saber.

-- 
Test your DAW with my Soundcard Attrition Page!
http://wkweb5.cableinet.co.uk/rwd
CDP homepage: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm


Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11405;
          13 Feb 99 9:31 GMT
Received: from [144.173.6.14] (helo=exeter.ac.uk)
	by wallace.maths.bath.ac.uk with esmtp (Exim 1.92 #2)
	for jpff@maths.bath.ac.uk
	id 10BbQC-0001r3-00; Sat, 13 Feb 1999 09:31:32 +0000
Received: from noether [144.173.8.10] by hermes via SMTP (JAA06388); Sat, 13 Feb 1999 09:29:50 GMT
Received: from sunny.ex.ac.uk by maths.ex.ac.uk; Sat, 13 Feb 1999 09:29:37 GMT
Received: from root@tempest.ocis.temple.edu [155.247.166.120] by sunny via ESMTP (JAA02336); Sat, 13 Feb 1999 09:29:37 GMT
Received: from localhost (kgallagh@localhost)
	by tempest.ocis.temple.edu (8.8.8/8.8.8) with ESMTP id AAA24539
	for ; Sat, 13 Feb 1999 00:51:59 -0500 (EST)
Date: Sat, 13 Feb 1999 00:51:59 -0500 (EST)
From: Kevin Gallagher 
X-Sender: kgallagh@tempest.ocis.temple.edu
To: Csound Discussion List 
Subject: more than one krate
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

I was just wondering, is there/could there be a way to have more than the
four rates p, i, k, and a for csound?  I'm doing some stuff in realtime so
I need to optimize bandwidth.  In getting rid of some pops and clicks, I
found that I need a high krate (3000+), but my realtime MIDI stuff often
demands a low krate (under 500).  Is there a way to have two krates, a
high one and a low one?  If not, what is a good workaround?

				Kevin Gallager, kgallagh@astro.temple.edu
				Web - http://astro.temple.edu/~kgallagh