djsundog/circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

Browse Source 
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
1 changed files with 6 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
shared-module/audiomp3/MP3Decoder.c
View File

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