When calling OggSeekFindEOS() from inside a OggVisitor callback, then
the #InputStream may be in the middle of an Ogg packet, and the newly
initialized #ogg_sync_state will not be able to load it without the
help of ogg_sync_pageseek(). By passing "synced=false" to
OggSeekFindEOS(), we force the use of ogg_sync_pageseek() even when
not actually seeking.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/719
This also reverts the previous commit which was wrong. When the
Vorbis decoder is disabled, we can't compile VorbisComments.cxx at
all.
Instead of expanding the #ifdef, this commit moves VorbisComments.cxx
to a separate library with dependencies on libvorbis (which was
missing previously, which could also lead to build failures if the
libvorbis headers were in a non-standard directory).
Apparently, libmpcdec sets gain/peak variables to zero if they are not
present. This clashes with our formula and results in bogus values
which cause noise during playback.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/640
SID files are generally collections of tunes, so a SID name field makes
sense as an MPD album. The SID tune information list (STIL) has name
and title fields for individual tunes, when such are known, but MPD is
currently not using the STIL.
High Voltage SID Collection (HVSC) metadata fields are encoded in
windows-1252, as described in DOCUMENTS/SID_file_format.txt:
https://www.hvsc.c64.org/download/C64Music/DOCUMENTS/SID_file_format.txt
If utf-8 transcoding fails, or the ICU library is unavailable, fall
back to plain ASCII and replace other characters with '?'.
This reverts commit f7ed7446ae. 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
Genres are not part of the SID format, so SID files are genreless. This
"default_genre" option may be used to assign a default genre to all SID
music, for example "SID", "C64", "Chiptune", etc.
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.
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