Re: [Audacity-devel] bug 434 invalid?

[Martyn S. <mar...@gm...>]

I think the title of this post says it all.  Please close it.

Martyn

On 23/10/2013 12:57, Steve the Fiddle wrote:
> Cc'd to devel as the root of this lies in the code and (in Martyn's
> words) deep questions about the nature of time ;-).
>
>
> Although double precision is extremely accurate, it is not exact (for
> example there is no exact binary representation of decimal 0.1),
> therefore a small amount of rounding is inevitable. Because of this
> rounding, three selections that have "exactly" the same duration, but
> different start times, may have very slightly different durations when
> represented as binary numbers.
>
> The Truncate Silence effect uses double precision for storing time
> values, so it is extremely accurate, but still not always "exact". The
> accuracy is usually around 15 decimal places.
>
> The current "fudge fix" to bug 434 suppresses the symptoms from the
> "steps to reproduce" but does not "fix the problem". There will still
> be some binary time values that are inexact such that "equal sized"
> silences will exhibit different behaviour.
>
> Martyn suggested that storing the start time and duration of the
> detected silences may improve the accuracy, but I don't believe that
> this will help because these times still need to be represented with
> possibly inexact binary numbers.
>
> When detecting the duration of the silence, Audacity counts the number
> of silent samples and converts that to a double precision time value,
> but depending on what those values are (ie the start time) the
> calculated duration may be rounded up or down a tiny amount and that
> tiny amount is enough to affect whether it is greater or less than the
> given decimal value.
>
> The "bug" does not appear to be an "off by one sample" error. The
> discrepancy that I am seeing when examining the code running is much
> much much smaller than that.
>
> Martyn provided some (verifiable) figures in comment 15:
> start time = 0.51700680272108845
> end time = 1.0170068027210883
> According to my calculator, that gives a duration of 0.5 seconds.
> One would therefore expect that the silence would be truncated if we
> are ignoring silences _less_than_ 0.5 seconds.
> However, my calculator is wrong due to having insufficient precision.
> The actual answer is 0.49999999999999985 seconds. As this is less than
> 0.5 it will not be truncated.
>
> Compare this with if the start time was 0.5 seconds.
> The binary representations of 0.5 and 1.0 are exact, thus when
> calculating the duration of silence, the calculation is:
> 1.0000 - 0.50000 = 0.5000000000 (exact)
> so if we ignore silences less than 0.5, this silence WILL be truncated.
>
> I've not looked at the code to see why Audacity 1.3.12 behaved
> differently - perhaps it was using float values rather than doubles,
> but that would not "solve the problem", it  would simply "move it
> along" so that the symptoms appear in different places.
>
> I think that the current "fudge fix" is as good as it gets. It does
> not "solve the problem", but it does make it harder to reproduce the
> symptoms because it pushes the problem away from exact millisecond
> values. The code comment should probably be updated to something like:
> // Is silence 'significantly' shorter than allowed silence (see bug 434).
>
> Steve
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>