Skip the frame during decode, which will likely incur a BADDATAPTR error
on the first frame, as has already been logged in the development
process. Instead, skip the first frame, then proceed to the next one.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This reverts commit 453e29b2f5. Also it
applies a different workaround for VBRI headers, which doesn't require
patching libmad to work.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This header type was missing, causing some Fraunhofer VBR MP3 files to
decode the wrong length information.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
There was a slight bug with handling Xing/LAME headers with main data
pointers indicating data preceding the header frame. This should allow
decoding their information properly.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Only do a rough estimation on files without Xing or LAME or iTunes
headers. This is much faster, even if less accurate, and may include
the footer tag if present.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This should prevent a crash if the input is recycled for another file,
which would cause the output buffer to be freed, but the output size to
contain a count on first call to readAudio, which would cause a memory
access crash.
Possibly fixes#269
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
The properties function should not be dereferencing an invalid index
into the layer codec name array if layer is not set to 1 through 3. This
could happen if, for instance, an MP3 file has an invalid ID3v2 tag.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This condition would underflow when skipping a bunch of samples on the
start of playback, or otherwise seeking, and could cause an unsigned
underflow, which would cause the subsequent vDSP_vflt32 to overread into
the MAD sample buffer and crash.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
FFmpeg processed files may also contain the LAME tag magic of 'Lavf' or
'Lavc', not just 'LAME'. Missed this when I was maintaining the FFmpeg
code that handles this, or at least adding iTunes support to it.
Fixes#250 again.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This time, a two-fer. First, ensure that file start seeking still skips
over the Xing/LAME header packet properly. Then, ensure that decoding
the last desired packet of the file does not indicate having decoded
more sample data than desired, which may have caused errors when
resuming playback position on restart and then smoothly transitioning to
the next track.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This is a possible fix for another gap issue I experienced, and may be
exposed by seeking from the start of the file without decoding first.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This error was caused by the necessary fix of the previous commit, only
it caused something completely different. Due to the fact that MP3 is
included in the list of formats supported for embedded CUE Sheets, the
open stage performs a seek to the file start after opening the file,
even if there is no sheet embedded. And the resulting seek was supposed
to be a null operation, since the file was already at the start. But, as
a result, this reset the start skip counter to zero, and because the
offset wasn't backwards, but to the same position, it didn't reset the
skip counter to the start of track delay. So, as a result, start of
track delay wasn't being removed, introducing a gap. Now, this change
bypasses the seek function altogether if seeking would do nothing from
the current playback position. Whew.
Fixes#250 and MP3 gaplessness in general, surprised I didn't notice
this sooner myself, but I guess I didn't bother to verify whether my
change would break anything. Whoops.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
A backwards comparison led to seeking forward doing a full seek up from
the file start, and seeking backwards being a non-functional operation,
so the file would just continue playing as if there were no seek.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
The total frames count in the iTunSMPB header is the encoded length, so
add the start and end padding to it for the decoder implementation,
which expects this variable to contain the total decodable length
including the start and end padding. Fixes gapless decoding of iTunes
files.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
A variable wasn't being used, except in debug builds. Comment out its
use and only skip over the field in the LAME header.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
There was a stupid bug in the previous commit I made, which caused local
or seekable MP3 files to crash the player on decode. This fixes that, by
checking that a packet has actually been decoded before touching the
packet info structures. Dumb, dumb, dumb error on my part.
Fixes#244
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Support the weird scenario of format changes mid-stream. Probably
highly unlikely, and likely to break things if it does occur, but
whatever, it might actually happen in some weird file.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
The current buffer size argument is used to determine if a buffer should
be allocated on the next run. Just in case something reuses the same
decoder instance.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
No idea if this brings a noticeable improvement, but it probably makes
better sense to only do the division step one time instead of doing it
twice interleaved when processing stereo files, which are the most
common scenario anyway.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Now Cog supports freeformat MP3 once again. The plugin has been extended
to include sample accurate seeking, accurate length probing of files
missing headers, and iTunes gapless info reading using libid3tag.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Christopher Snowhill