## audacity-quality

 [Audacity-quality] bug 434 invalid? From: Steve the Fiddle - 2013-10-23 11:57:53 ```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 ```
 Re: [Audacity-quality] [Audacity-devel] bug 434 invalid? From: Martyn Shaw - 2013-10-24 22:57:09 ```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 > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ```
 Re: [Audacity-quality] [Audacity-devel] bug 434 invalid? From: Vaughan Johnson - 2013-10-25 05:13:37 ```Indeed, this is not new science. ;-0 - V On 10/24/2013 3:57 PM, Martyn Shaw wrote: > 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 >> audacity-devel@... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > > ------------------------------------------------------------------------------ > 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-quality mailing list > Audacity-quality@... > https://lists.sourceforge.net/lists/listinfo/audacity-quality > ```
 Re: [Audacity-quality] [Audacity-devel] bug 434 invalid? From: Steve the Fiddle - 2013-10-25 17:35:11 ```I can see Gale's point that it "looks wrong" if silences of equal length are sometimes truncated and sometimes not, so I think that the "fudge fix" is useful in moving the rounding issue away from exact milliseconds. However, the 0.1 millisecond allowance is a lot more than actually required and may create unexpected results when using high sample rates, so I've posted a patch that replaces the FIXME comment with a comment that explains what the "fudge fix" does, and reduces the "fudge" to 1 nanosecond, which I think should be accurate enough for anyone. I've also posted a Nyquist script to bugzilla to aid with testing the "fix". Note that there will always be some apparent weirdness in certain cases - for example, 513 milliseconds at 96000 Hz is 49248 samples, which is exactly 513 milliseconds, whereas 513 ms at 44100 Hz is 22623.3 samples, but because samples must be whole numbers the duration in samples is 22623 = 512.993 ms. If QA is happy with the patch, I think it should be applied so as to remove the FIXME comment more than anything else, then this bug can be closed. Steve On 25 October 2013 06:13, Vaughan Johnson wrote: > Indeed, this is not new science. ;-0 > > - V > > > On 10/24/2013 3:57 PM, Martyn Shaw wrote: >> 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 >>> audacity-devel@... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >> >> ------------------------------------------------------------------------------ >> 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-quality mailing list >> Audacity-quality@... >> https://lists.sourceforge.net/lists/listinfo/audacity-quality >> > > ------------------------------------------------------------------------------ > 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-quality mailing list > Audacity-quality@... > https://lists.sourceforge.net/lists/listinfo/audacity-quality ```

## Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks