... 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
* Fix building without libid3tag
* Fix building without libid3tag
Extend the pull Audacity#214 from torto9 to fix building
with twolame but without libid3tag
... Avoid small out-of-context words and phrases in translation catalog that
are then substituted into larger translated phrases with blanks.
(What if my language has declensions? How do I know the right form to use
for the phrases?)
Instead, give the translators larger in-context phrases to work with, even if
that requires replications of phrases with small variations.
... and similar wx "variadics," which all treat wxString smartly enough that
you don't need this.
Don't need c_str either to convert wxString to const wxChar * because
wxString has a conversion operator that does the same.
- Dead code from experiments in SelectionBar removed.
- Many warnings about unused parameters fixed with WXUNUSED()
- Many warnings about signed / unsigned comparisons cleaned up.
- Several 'local variable declared but not used' warnings fixed.
"seconds" and "Output" are translated elsewhere, so just add _
New string _("%") will simply go through untranslated for now but can be in next
version's audacity.pot
... It was seen to happen, at least for some MIDI files on Windows, because
the FFmpeg library may render them without reporting an error, but the rendering
was really bad!
Simplify the logic of duplication of NoteTrack. Duplicates are always in
serialized state. Un-serialization can happen on demand in any of the
NoteTrack operations that require a defined sequence.
Changing the duration of the sequence after paste is needed,
as it was also needed, when I fixed Stretch at commit
90eb4ec142f7d575d0870dd9c755589bff520cbe. I don't know if this should be
considered a bug in Allegro that we are compensating.
The MAD decoder will not decode the final frame in an mp3 stream unless
it has a small amount of padding afterwards (MAD_BUFFER_GUARD bytes,
actually 8). Without this, it loses sync before returning any decoded
data from the final frame. The result is that the imported audio is
truncated by up to 1152 samples.
This commit addresses that by using a final round of input callback
calls to provide the last MAD_BUFFER_GUARD bytes after the underlying
file has reached eof. The logic is based on madplay.
... whenever they really describe the size of a buffer that fits in memory, or
of a block file (which is never now more than a megabyte and so could be fit in
memory all at once), or a part thereof.
... A non-narrowing conversion out to long long is a necessity, but the
conversions to float and double are simply conveniences.
Conversion from floating is explicit, to avoid unintended consequences with
arithmetic operators, when later sampleCount ceases to be an alias for an
integral type.
Some conversions are not made explicit, where I expect to change the type of
the variable later to have mere size_t width.
... Define lots of operators for disambiguation, but they will go away after
all conversions from sampleCount to built-in numerical types are forced
to be explicit.
