toward floating-point?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

toward floating-point?

Cory Nelson
The more I play around with sox, the more annoying it is to constantly
guess what gain to apply to avoid clipping (-G doesn't work for
everything).

I know changing at this point would be a large effort but I'm still
curious, why does sox use integers instead of floating-point?  It'd
easily avoid this problem and is as fast if not faster than integer
math on modern CPUs.

--
Cory Nelson
http://int64.org

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Jan Stary
On Mar 05 10:20:34, Cory Nelson wrote:
> The more I play around with sox, the more annoying it is to constantly
> guess what gain to apply to avoid clipping (-G doesn't work for
> everything).
>
> I know changing at this point would be a large effort but I'm still
> curious, why does sox use integers instead of floating-point?  It'd
> easily avoid this problem and is as fast if not faster than integer
> math on modern CPUs.

Perhaps I am missing something here,
but how would that make gains not clip?


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Rob Sykes
In reply to this post by Cory Nelson
From: Cory Nelson <[hidden email]>
To: [hidden email]
Sent: Monday, 5 March 2012, 16:20
Subject: [SoX-users] toward floating-point?

The more I play around with sox, the more annoying it is to constantly
guess what gain to apply to avoid clipping (-G doesn't work for
everything).

Do you have an example?  There may be a fix or a work-around.


I know changing at this point would be a large effort but I'm still
curious, why does sox use integers instead of floating-point?

It's largely historical: in 1991, few could afford an FPU and sox was primarily a format (header) conversion tool. These days, almost all the effects use floating-point, so building an integer-only version of sox is not really on.

Cheers,
Rob

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Rob Sykes
In reply to this post by Jan Stary

>Perhaps I am missing something here,
>but how would that make gains not clip?


Because FP can represent very large numbers, clipping in the effects chain becomes very unlikely, and a (downwards) normalisation could be applied at the end of chain to bring things back in check.

/Rob

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Cory Nelson
In reply to this post by Rob Sykes
On Mon, Mar 5, 2012 at 10:53 AM, robs <[hidden email]> wrote:

> From: Cory Nelson <[hidden email]>
> To: [hidden email]
> Sent: Monday, 5 March 2012, 16:20
> Subject: [SoX-users] toward floating-point?
>
> The more I play around with sox, the more annoying it is to constantly
> guess what gain to apply to avoid clipping (-G doesn't work for
> everything).
>
> Do you have an example?  There may be a fix or a work-around.
>

Most recently I encountered this while using compand to prepare music
for playing in a car. (As an aside, compand keeps giving me a warning
that it expected a single channel but got two. Is this okay?)

>
> I know changing at this point would be a large effort but I'm still
> curious, why does sox use integers instead of floating-point?
>
> It's largely historical: in 1991, few could afford an FPU and sox was
> primarily a format (header) conversion tool. These days, almost all the
> effects use floating-point, so building an integer-only version of sox is
> not really on.

I figured it would be something like this. How realistic would it be
to gradually transition the entire pipeline to floating-point, perhaps
with an automatic filter applied to convert to/from integer for
filters which don't yet support it? I haven't looked at sox yet, but
I'd be willing to contribute some patches.

--
Cory Nelson
http://int64.org

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Jan Stary
In reply to this post by Rob Sykes
On Mar 05 17:04:04, robs wrote:
>
> >Perhaps I am missing something here,
> >but how would that make gains not clip?
>
>
> Because FP can represent very large numbers, clipping in the effects chain becomes very unlikely, and a (downwards) normalisation could be applied at the end of chain to bring things back in check.

I still don't get it: on my system, sizeof(float) = 4.
How can four-byte floats represent larger dynamic range
than four-bytes integers (which, if I remember right,
is currently SoX's internal sample format)?

        Jan


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Jan Stary
In reply to this post by Cory Nelson
On Mar 05 11:35:50, Cory Nelson wrote:

> On Mon, Mar 5, 2012 at 10:53 AM, robs <[hidden email]> wrote:
> > From: Cory Nelson <[hidden email]>
> > To: [hidden email]
> > Sent: Monday, 5 March 2012, 16:20
> > Subject: [SoX-users] toward floating-point?
> >
> > The more I play around with sox, the more annoying it is to constantly
> > guess what gain to apply to avoid clipping (-G doesn't work for
> > everything).
> >
> > Do you have an example?  There may be a fix or a work-around.
> >
>
> Most recently I encountered this while using compand to prepare music
> for playing in a car.

It is quite easy to introduce clipping with compand.
Also, please show how exacty -G fails with compand.

> (As an aside, compand keeps giving me a warning
> that it expected a single channel but got two. Is this okay?)

Sigh. Show the exact full command line, show the exact full output.
Then someone can possibly look at it.


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Cory Nelson
In reply to this post by Jan Stary
On Mon, Mar 5, 2012 at 1:09 PM, Jan Stary <[hidden email]> wrote:

> On Mar 05 17:04:04, robs wrote:
>>
>> >Perhaps I am missing something here,
>> >but how would that make gains not clip?
>>
>>
>> Because FP can represent very large numbers, clipping in the effects chain becomes very unlikely, and a (downwards) normalisation could be applied at the end of chain to bring things back in check.
>
> I still don't get it: on my system, sizeof(float) = 4.
> How can four-byte floats represent larger dynamic range
> than four-bytes integers (which, if I remember right,
> is currently SoX's internal sample format)?
>

Float has less precision (only 24 bits, which is plenty for audio),
but a much larger dynamic range. The point is that:

0.75 * 2 = 1.5 (can be normalized back to 1.0 range)
1610612735 * 2 = 2147483647 (clipped unrecoverably by 1/3rd)

It is practically impossible to unrecoverably clip while using float.
You'd need to have some pretty heroic and nonsensical filters.

--
Cory Nelson
http://int64.org

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Ulrich Klauer-2
In reply to this post by Jan Stary
Jan Stary <[hidden email]>:

> I still don't get it: on my system, sizeof(float) = 4.
> How can four-byte floats represent larger dynamic range
> than four-bytes integers (which, if I remember right,
> is currently SoX's internal sample format)?

For illustration, consider decimal numbers of four digits. Treated as  
unsigned integers, you may express values from 0 ("0000") or 1  
("0001") to 9999 ("9999") with them, so you have a dynamic range of  
9999:1 = 9999, or approximately 80 dB. Treated as floats however,  
"2718" were to be interpreted as 2.71*10^8 = 271000000, so you can  
express values from 1 ("1000") to 9990000000 ("9999"), and the dynamic  
range is about 200 dB. (It might even be a bit more, if you allow  
denormalized numbers like "0010" = 0.001.)

The trade-off involved is, of course, that you can't express the  
difference between 9990 and 9994 with our "decimal floats".

Ulrich


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Doug Cook-2
In reply to this post by Cory Nelson
> I figured it would be something like this. How realistic would it be
> to gradually transition the entire pipeline to floating-point, perhaps
> with an automatic filter applied to convert to/from integer for
> filters which don't yet support it? I haven't looked at sox yet, but
> I'd be willing to contribute some patches.

I've given this some thought, but unfortunately it just hasn't been
important enough to me for it to graduate from thought experiment to
working code.

I thought that the ideal would be to simply not have any kind of
"native" encoding. Sox should accept data in the encoding provided and
pass it on in the encoding requested. The input format handler tells
sox what encoding it produces. Effects tell sox what encoding(s) they
accept and what encoding(s) they can produce. The output format
handler tells sox what encoding it needs. Sox adds encoding conversion
steps between each effect as needed, just like it already
automatically adds channel/sample rate/dithering/etc. steps.

In theory, this could make sox work much more efficiently. Many of the
effects take the 32-bit integer input, convert to double, perform the
effect's calculation, then convert back to 32-bit integer. When
several of these double-based effects are chained together, it would
be much more efficient to simply leave the data in double and skip all
the conversion.

That was my theory -- for a while anyway.

In practice, all effects in an audio processing chain should meet a
similar minimum standard. If the minimum standard is 24 bits of
precision, all effects should be designed to provide 24 bits of
precision. If the standard is 120 dB of dynamic range, all effects
should be able to provide that too. A piece of audio processing
software will be designed with a particular standard in mind, and the
effects will then be built to meet or beat that standard as
efficiently as possible. And that means the effects will converge on a
single "preferred" encoding.

That said, it is definitely interesting to consider whether sox's
current preferred encoding is the right one. Seeing as how you
essentially can't do anything useful in sox without the sample being
converted to a double at least once (for example, any gain adjustment
involves a floating-point multiply), I'm pretty confident that the
best choice of preferred encoding for sox is a floating-point format,
not an integer format. That means it would be a fight between float32
(float) and float64 (double).

As an aside, the fact that all of sox's internal floating-point work
occurs in double should not prejudice the discussion. Double is used
because the current standard is int32, and you lose up to 7 bits of
precision when you convert from int32 to float32, so float32 couldn't
be used for intermediate results if the standard encoding is int32.

In any case, there are two questions unanswered in my mind. First,
which would be better as the standard encoding for sox: float32 or
float64?

The 24 bits of precision provided by float (or 25, depending on how
you count) is more than enough for any finished product, but sox is
involved in intermediate results, not just finished products. 24 bits
of precision, if carefully maintained in all calculations, is probably
good enough even for intermediate results, but properly maintaining
the precision of floating point numbers (ensuring that you lose
minimal precision in each calculation) is very tricky, especially
cross-platform.

Based on the way I use sox for my own needs (very simple usage), I'm
pretty sure that my ears would never be able to tell the difference
between the results of a float32-based sox and a float64-based sox.
But others might be using more complicated effects chains and might
notice a difference.

In addition, based on the way I use sox, the processing time
difference between a float32-based sox and a float64-based sox would
probably never be noticed. A float64-based sox might take a few
milliseconds longer to encode something, but it probably wouldn't
affect me. In fact, on an x86, there might not be any difference at
all. But on an arm chip, or perhaps in the future when somebody wants
to make sox do SSE-optimized (or GPU-optimized) vectorized effects
calculations, the difference between a 32-bit and 64-bit float might
be more significant.

The second unanswered question is how much any of this matters. A
floating-point format would make some normalization tasks easier, but
the current system also works fine. And just as my ears can't tell the
difference between float32 and float64, they probably also can't tell
the difference between int32 and float64. Where would this fit in a
list of sox feature requests? For my needs, it wouldn't rank very
high. But it probably wouldn't be really hard, and it would make sox
a lot more flexible.

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Cory Nelson
On Sat, Mar 10, 2012 at 1:19 AM, Doug Cook
<[hidden email]> wrote:

> That said, it is definitely interesting to consider whether sox's
> current preferred encoding is the right one. Seeing as how you
> essentially can't do anything useful in sox without the sample being
> converted to a double at least once (for example, any gain adjustment
> involves a floating-point multiply), I'm pretty confident that the
> best choice of preferred encoding for sox is a floating-point format,
> not an integer format. That means it would be a fight between float32
> (float) and float64 (double).
>
> As an aside, the fact that all of sox's internal floating-point work
> occurs in double should not prejudice the discussion. Double is used
> because the current standard is int32, and you lose up to 7 bits of
> precision when you convert from int32 to float32, so float32 couldn't
> be used for intermediate results if the standard encoding is int32.
>
> In any case, there are two questions unanswered in my mind. First,
> which would be better as the standard encoding for sox: float32 or
> float64?
>
> The 24 bits of precision provided by float (or 25, depending on how
> you count) is more than enough for any finished product, but sox is
> involved in intermediate results, not just finished products. 24 bits
> of precision, if carefully maintained in all calculations, is probably
> good enough even for intermediate results, but properly maintaining
> the precision of floating point numbers (ensuring that you lose
> minimal precision in each calculation) is very tricky, especially
> cross-platform.

Float32 might not be so bad for intermediate results. For instance, a
negative gain will essentially drop effective bits from an int32
sample, while a single-precision float will maintain its full
precision.

If calculations are kept in double form, less simple filters would
still be able to maintain a full 24 bits of precision pretty easily.

I do suppose, though, that if sox's goal is to maintain highest
fidelity that a full double-precision pipeline would be required,
however overkill that may be.

> Based on the way I use sox for my own needs (very simple usage), I'm
> pretty sure that my ears would never be able to tell the difference
> between the results of a float32-based sox and a float64-based sox.
> But others might be using more complicated effects chains and might
> notice a difference.
>
> In addition, based on the way I use sox, the processing time
> difference between a float32-based sox and a float64-based sox would
> probably never be noticed. A float64-based sox might take a few
> milliseconds longer to encode something, but it probably wouldn't
> affect me. In fact, on an x86, there might not be any difference at
> all. But on an arm chip, or perhaps in the future when somebody wants
> to make sox do SSE-optimized (or GPU-optimized) vectorized effects
> calculations, the difference between a 32-bit and 64-bit float might
> be more significant.

Indeed. Short of div/sqrt, there's no difference in speed between
single and double on any modern x86. Depending on the complexity of
calculations, the extra bandwidth usage of double might even be hidden
by a CPU's prefetching.

With ARM getting more relevant, though, I guess it is important to
take it into consideration and I've got no clue how it handles double
or prefetching.

> The second unanswered question is how much any of this matters. A
> floating-point format would make some normalization tasks easier, but
> the current system also works fine. And just as my ears can't tell the
> difference between float32 and float64, they probably also can't tell
> the difference between int32 and float64. Where would this fit in a
> list of sox feature requests? For my needs, it wouldn't rank very
> high. But it probably wouldn't be really hard, and it would make sox
> a lot more flexible.

For me it's got nothing to do with quality—I agree no human ears would
ever be able to tell the difference between int/float/double. Even the
best of DACs average less than 20 bits of precision (as a full device,
not an imaginary IC spec) and most "prosumer" devices are lucky to hit
18 bits. As far as listening gues, 16 bits is perfectly fine so long
as volume is controlled at the amp.

Short of heroic filter chains, I doubt the resulting samples would be
significantly changed for anyone either. Such filter chains would no
doubt be altering the audio enough to make a small loss of
intermediate precision go entirely unnoticed.

The current guard system does work fine for most of the filters,
though it really, really sucks when you happen upon one where it
doesn't (like compand) and just need to take wild guesses until you
find a gain that works. This is really my only motivation here.

--
Cory Nelson
http://int64.org

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Ulrich Klauer-2
Cory Nelson <[hidden email]>:

> The current guard system does work fine for most of the filters,
> though it really, really sucks when you happen upon one where it
> doesn't (like compand) and just need to take wild guesses until you
> find a gain that works. This is really my only motivation here.

I think switching to floating-point wouldn't help you there. The  
lowpass, highpass, equalizer etc. filters simply amplify part of a  
signal by, say, 20%, and it's irrelevant whether that's from 0.8 to  
0.96, or from 0.01 to 0.012, or whatever. The compand effect, however,  
looks at absolute levels and may change 0.8 to 0.96, but 0.01 to 0.2.  
That's its very purpose, otherwise we could replace it with gain or vol.

So instead of manually fiddling with the gain to avoid clipping, you'd  
have to manually fiddle with the gain to get the signal to the right  
level for companding. (Alternatively, you'd have to manually fiddle  
with the transfer function.)

> Doug Cook <[hidden email]>:
>> That said, it is definitely interesting to consider whether sox's
>> current preferred encoding is the right one. Seeing as how you
>> essentially can't do anything useful in sox without the sample being
>> converted to a double at least once (for example, any gain adjustment
>> involves a floating-point multiply), I'm pretty confident that the
>> best choice of preferred encoding for sox is a floating-point format,

I tend to agree, seeing how much processing time is burned by  
SOX_ROUND_CLIP_COUNT alone. On the other hand, format conversion  
without applying any effects would take longer in most cases if all  
data had to take a floating-point transit.

Perhaps only the effects chain should use FP, not the format handlers.  
Then again, there are some file formats that store FP data ...

>> not an integer format. That means it would be a fight between float32
>> (float) and float64 (double).
...
>> A float64-based sox might take a few
>> milliseconds longer to encode something, but it probably wouldn't
>> affect me. In fact, on an x86, there might not be any difference at
>> all. But on an arm chip, or perhaps in the future when somebody wants
>> to make sox do SSE-optimized (or GPU-optimized) vectorized effects
>> calculations, the difference between a 32-bit and 64-bit float might
>> be more significant.

I'm not really sure of the x86 thing, not for the CPU cycles, but for  
the cache size that effectively halves when you go from 4 bytes to 8  
bytes per samples. Cache size is very important, just try increasing  
--buffer until it doesn't fit anymore.

In principle, I'm in favour of keeping as much precision as possible,  
so that would mean float64. But as float32 and float64 behave very  
similar from a C perspective, it might be possible to offer both  
float32 and float64 as a compile-time option. Most code would simply  
use sox_sample_t and, where necessary, macros like  
SOX_FLOAT_32BIT_TO_SAMPLE as today that would be #defined away in the  
float32 version. Few functions (like those that compute sample  
precision) would need to look under the hood.

Perhaps additionally supporting float128 (double double) would make  
SoX attractive to certain audiophiles. :-)

> With ARM getting more relevant, though, I guess it is important to
> take it into consideration and I've got no clue how it handles double
> or prefetching.

I think you can't speak of "ARM" by itself; it's more like a  
collection of building blocks that a vendor may choose from. They  
certainly offer fast float64 logic, too, but a vendor may refrain from  
including it for cost or power usage reasons.

>> The second unanswered question is how much any of this matters. A
>> floating-point format would make some normalization tasks easier, but
>> the current system also works fine. And just as my ears can't tell the
>> difference between float32 and float64, they probably also can't tell
>> the difference between int32 and float64. Where would this fit in a
>> list of sox feature requests? For my needs, it wouldn't rank very
>> high.

I agree, also regarding priority. I'd rather see it as a speed  
optimization for effects processing.

Ulrich


------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Rob Sykes




----- Original Message -----
> From: Ulrich Klauer <[hidden email]>
> I tend to agree, seeing how much processing time is burned by 
> SOX_ROUND_CLIP_COUNT alone. On the other hand, format conversion 
> without applying any effects would take longer in most cases if all 
> data had to take a floating-point transit.



Yes, clipping detection is slow, but it can be useful to know that clipping has occurred in a particular effect as if you're pretty sure that your effect chain shouldn't clip then its a flag to let you know you've mistyped something (or some other process has gone wrong) before or at the point of clipping.


It can also be a concious decision to allow clipping to occur in an effect (acting as a crude limiter) to avoid normalisation (perhaps pushing down the volume of the whole track for the sake of one rogue peak).

Without clipping detection, the signal is effectively uncontrolled and might be at an arbitrary level at the input to effects which work on absolute levels (compand for example) so other control mechanisms might be necessary.

AGC might be possible, but we can't rely on a normalisation stage, for streamed audio (e.g. recording) at least, and ultimately, out-of-range samples have to be brought in range if writing to an integer-based format.

So playing "fast and loose" with levels in the chain may just be storing up problems for later?  It might be instructive to see what successful commercial tools do here, or to look at the design of standard effects plug-in architectures (VST, LV2, etc.)—it has been suggested in the past to ditch the current effects arch. and replace it with a standard one.

Food for thought :)

Cheers,
Rob

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: toward floating-point?

Ulrich Klauer-2
robs <[hidden email]>:

> Yes, clipping detection is slow, but it can be useful to know that  
> clipping has occurred in a particular effect as if you're pretty  
> sure that your effect chain shouldn't clip then its a flag to let  
> you know you've mistyped something (or some other process has gone  
> wrong) before or at the point of clipping.
>
> It can also be a concious decision to allow clipping to occur in an  
> effect (acting as a crude limiter) to avoid normalisation (perhaps  
> pushing down the volume of the whole track for the sake of one rogue  
> peak).

I remembered reading this thread on Hydrogenaudio where someone  
explicitly wants to do clipping:  
http://www.hydrogenaudio.org/forums/index.php?showtopic=93150
So, yes, I guess a "clip" effect could be needed that is inserted at  
the end of an FP effects chain automatically (at least when writing an  
integer-based file format) or can be inserted manually where desired.

A normalization stage (that can't be turned off) is not what I'd like to have.

Ulrich


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: [SoX-devel] toward floating-point?

Rob Sykes
In reply to this post by Ulrich Klauer-2
> Cory Nelson <[hidden email]>:
>
>>  The current guard system does work fine for most of the filters,
>>  though it really, really sucks when you happen upon one where it
>>  doesn't (like compand) and just need to take wild guesses until you
>>  find a gain that works. This is really my only motivation here.


Have you tried compand with a gain of say -40 followed by a norm or perhaps replay-gain?

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users