MP3Decoder: better handle indicating end of mp3 audio data to caller

The old formulation
 * wouldn't work if there were ID3 tags at the end
 * would choose whether to background-refill the inbuf
   based on a check before skipping to the next sync word, which
   could be incorrect.

I think it was aspect "B" that ended up triggering the erroneous EOF
problem fixed in the prior commit. This would depend on specific data
sizes and offsets occuring in the file such that a read would be
scheduled but then the buffer would be filled and left 100% full by
find_sync_word(). It's just lucky(?) that a particular person produced
such a file, and/or many files produced by Audacity have those
characteristics.
This commit is contained in:
Jeff Epler 2022-04-22 14:10:38 -05:00
parent 1841af90e2
commit df5f7bc765
No known key found for this signature in database
GPG Key ID: D5BF15AB975AB4DE

View File

@ -356,6 +356,11 @@ audioio_get_buffer_result_t audiomp3_mp3file_get_buffer(audiomp3_mp3file_obj_t *
return GET_BUFFER_DONE; return GET_BUFFER_DONE;
} }
self->samples_decoded += *buffer_length / sizeof(int16_t);
mp3file_skip_id3v2(self);
int result = mp3file_find_sync_word(self) ? GET_BUFFER_MORE_DATA : GET_BUFFER_DONE;
if (self->inbuf_offset >= 512) { if (self->inbuf_offset >= 512) {
background_callback_add( background_callback_add(
&self->inbuf_fill_cb, &self->inbuf_fill_cb,
@ -363,8 +368,7 @@ audioio_get_buffer_result_t audiomp3_mp3file_get_buffer(audiomp3_mp3file_obj_t *
self); self);
} }
self->samples_decoded += *buffer_length / sizeof(int16_t); return result;
return mp3file_find_sync_word(self) ? GET_BUFFER_MORE_DATA : GET_BUFFER_DONE;
} }
void audiomp3_mp3file_get_buffer_structure(audiomp3_mp3file_obj_t *self, bool single_channel_output, void audiomp3_mp3file_get_buffer_structure(audiomp3_mp3file_obj_t *self, bool single_channel_output,