No distinction between skipped ID3 or invalid data

[ceigel]

Hi, I'd like to be able to distinguish between a frame that doesn't have all its data and an id3 frame. I am trying to decode a file that doesn't fit inside RAM (of a microcontroller), so I allocate a buffer of 16384 bytes and try to find the last complete buffer. I pass null pointer as the buffer for the PCM samples. I get a bunch of frames, and then the last one is truncated. I'd like to detect the truncated frame. For the truncated frame I get 0 samples and the following mp3dec_frame_info_t: {frame_bytes: 157, frame_offset: 0, channels: 2, hz: 44100, layer: 3, bitrate_kbps: 128}. So according to the documentation this is "skipped ID3 or invalid data" If I increase the data size (to 16384 + 1024 bytes) the same frame would read with 1152 samples and mp3dec_frame_info_t{frame_bytes: 418, frame_offset: 0, channels: 2, hz: 44100, layer: 3, bitrate_kbps: 128}

[lieff]

Hi :) If I understand correctly - frames decoded till end of 16384 buffer. It's not how it's supposed to work. Buffer must be filled with at least 16384 bytes on every mp3dec_decode_frame invocation.

Also better to remove ID3 v1/v2 early or there can be edge cases. Because for example id3v2 can be 16384-1 bytes and we accidentality skip first byte of first good frame. Solution can be do not skip all 16384, but 16384 - MAX_FREE_FORMAT_FRAME_SIZE, but it's better just support id3v2 skipping.

To see how correctly support all this stuff look at mp3dec_load_cb implementation. You also can try use mp3dec_ex_open/mp3dec_ex_read and reduce MINIMP3_IO_SIZE to 16384 for embedded usage.

[ceigel]

I can't actually use mp3dec_ex_open/mp3dec_ex_read because I am doing all this in a no-stdio environment. No matter, thanks for the pointers. I also took a look at mp3dec_load_cb. Ideally what I want to achieve is a ring buffer where I don't move bytes around. Also I have about 20k for all this. I can also remove the ID3 v1/v2 header and frames. I have a question about the restriction of 16k buffer for each call to mp3dec_decode_frame. How exactly does this happen at the end of the mp3 file. There needs to be at least a time for each file where mp3dec_decode_frame is going to be called for less than 16k of data. That is at the end. Maybe some mp3 is less than 16k, how does it work then?

Thanks again...

[lieff]

Ideally what I want to achieve is a ring buffer where I don't move bytes around.

Yes magic ring buffer can help with that.

I have a question about the restriction of 16k buffer for each call to mp3dec_decode_frame. How exactly does this happen at the end of the mp3 file. There needs to be at least a time for each file where mp3dec_decode_frame is going to be called for less than 16k of data. That is at the end. Maybe some mp3 is less than 16k, how does it work then?

For end of file just rest of the buffer should be passed (without id3v1 and apev2 tags), so buffer can be less than 16384 only in eof condition. You can lower 16384 requirement by relaxing sync procedure. Change MAX_FRAME_SYNC_MATCHES from 10 to 5 or 3 and you can try 8192 io buffer.