... Assuming that large unsigned magnitudes with high order bit set are not
the problem, but signed negatives of small magnitude may be:
1) Always cast the unsigned to signed in comparisons, not the other way.
Also:
2) Cast unsigned TERM to signed by itself, before subtracting. Don't cast
the result.
3) Rewrite some comparisons by moving subtracted term to other side.
See commits
d2fe7b1757d77d93d82d53685a118517a4d2e996
f463eda36c059236ecc168919c745eb687170c95
This fixes the file truncation (missing last ~1000-2000 samples)
on file export. It will also eliminate error dialog some users
have witnessed.
Also cleans up the code
- simplified the Finalize function
- add error dialog for encoder errors
- always writes a final frame even if it has to pad with silence
- correctly determine when a codec supports short final frame
... Now restores state again properly and does not cause undocking of other
bars when you restart.
Redoes commit 2d56c8ec3286aa0a4a22e5be9148a2a1e01b8e17 better
... Also checked more error returns from library functions. Detect it when
write fails (maybe because of exhaustion of space) -- don't continue,
pretending all is still well.
Using one non-specific error message in many places, because we're in string
freeze now.
... Problem was a wrongly implemented comparator for wxArray Sort().
The array of points was not really sorted, and results differed with repeated
calls to Sort().
Unlike with std::sort, these comparators are supposed to be trichotomous.
Problem dates to commit 7d5e54e364fcccd630274f2658703543d8c596eb
See also commit 4a500c77dda5592468f931db0c791236679157b4
... doing that only for the user-visible string, seen in the Manage>About menu
of the effect dialog and in the sorted or grouped Effect/Generate/Analyze
menus.
But don't for the string used internally and written into pluginregistry.cfg,
so that compatibility of that file is preserved.
See also commits cafbff9ff82520ff7d4344570385752869c6d230 and
c6bbe4c3dae8a52bb4b7a3c720af97bc3bd69769
... The part that checks the previously unused statusFlags argument of
audacityAudioCallback can make zero-length labels. I did provoke this into
happening repeatably on macOS using a debug build, zero buffer length in device
preferences, and a busy CPU running other programs, within just two minutes of
recording.
But close zooming in on the label, and listening, revealed nothing obviously
wrong, no click in the playback. So I consider that a false positive.
But the part of the drop-out detection that would make nonzero length
labels, because the other AudioThread is lagging in its writes to disk --
this part remains. Yet I have not yet provoked this into happening.
