Found with modernize-loop-convert
Signed-off-by: Rosen Penev <rosenp@gmail.com>

max_frames is size_t, not unsigned long. Fixes GCC warning.

Why would anybody want to keep the silence inserted by the codec?
Other plugins/codecs (such as Vorbis) have this hard-coded as well.

This reverts commit f7ed7446.  It was
a bad idea, because MAD_F_MIN and MAD_F_MAX do not represent the
clamping limits, but the theoretical minimum and maximum values of the
mad_fixed_t data type.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/617

Much of that is not possible when mad_header_decode() has already been
called.

libmad has a hard-coded maximum PCM buffer size; if we make our
output_buffer just as large, we can avoid the loop, because any
possible size will fit.

These will not be used until they are initialized in SyncAndSend().

Apparently, libmad not only inserts 529 samples of silence at the
beginning of the file, but also removes them at the end.

This solves the last piece of
https://github.com/MusicPlayerDaemon/MPD/issues/601

Closes https://github.com/MusicPlayerDaemon/MPD/issues/601

libmad requires padding the input buffer with "MAD_BUFFER_GUARD" zero
bytes at the end of the file, or else it is unable to decode the last
frame.

This fixes yet another bug which prevented this plugin from decoding
the last frame, see
https://github.com/MusicPlayerDaemon/MPD/issues/601

The Xing/LAME frame indicates how many frames there are, but that
excludes the initial Xing/LAME frame.  Therefore, it should not be
counted.

This fixes an off-by-one bug which caused the last frame to be
skipped, fixing one part of
https://github.com/MusicPlayerDaemon/MPD/issues/601

Increment "current_frame" after processing the frame.

This also fixes a bug which caused the bit rate to not update after
seeking.

Broken since commit f8bfea8b