mad expects extra bytes at the end of a buffer (see discussion in
http://www.mars.org/mailman/public/mad-dev/2001-May/000262.html),
and since we inject these without the base class' knowledge, we
need to hide the bodies better.
This fixes an assert at EOS when decoding an mp3 manually without
an intervening mpegaudioparse.
If http://www.mars.org/mailman/public/mad-dev/2001-May/000262.html is
to be believed, the last buffer must be followed by a number of 0 bytes
in order for the last frame to be decoded (at least in some cases).
Doing so seems to work here, fixing a missing 1152 samples when using
mp3parse before mad (not using mp3parse would yield the correct amount
of samples, if there's extra non-MP3 data after (eg, tag data)).
This time using the base class. Still something
wrong with the parsing though, when there's no
parser or demuxer upstream (which of course
shouldn't happen in a normal playback scenario).
Taken from commit 6e7e3657396454fe95fbd89170281865d4d1cec3
of Mark's baseaudio branch.
Would probably be too risky to drop this into 0.10 given
all the things mad is doing.
The mad mp3 decoder element shouldn't parse tags at all really, but we
have so far kept this code around for backwards-compatibility reasons
for people building manual pipelines for some reason. However, as it
turns out that code has never actually worked in 0.10 in practice,
since it only gets executed if mad_frame_decode() returns LOSTSYNC,
which doesn't actually seem to happen any more though because of the
preceding mad_header_decode(), which will discover and report the
sync loss if it runs into a tag and make mad_frame_decode() try to
resync right away.
Discovered this while trying to make it use gst_tag_list_from_id3v2_tag().
ID3 tags are usually handled by id3demux, and should be handled
by id3demux. Tag handling in mad based on libid3tag is very basic
and mostly unnecessary really, so just build this plugin without
ID3 tag support if libid3tag is not available.
