Open 6r0m opened 2 months ago
Was the MP3 encoded with LAME? If so it might relate to #263
@eXpl0it3r thank you for pointing out!
yes it's Lame and very weird that the first chunk without silence at the beginning. seems that at the first chunk there is still some info with Lame data but in the separated frames isn't.
maybe do you know how to solve it in the context dr_mp3 or need to switch to the minimp3?
I tried to understand and implement a tag filtering, but failed to properly understand a) what needs to be parsed and b) at which level to add it.
Still hoping for someone else to stop by and fix it, as it's blocking the swap from minimp3 in SFML (which causes different issues): https://github.com/SFML/SFML/pull/2995
@mackron please help
I've integrated minimp3 and the result was the same, until I fully realized that I can't just reinit decoder/info on new portion of data, seems it's tracking some sequence of mp3 frames and if initial decoder state doesn't match initial bits then whole sequence will be dropped until new with initial bits received. I guess it's for all mp3 codecs or Lame specific.
Hi, Thank you for your libs!
I have issue with the stream decoding. problem that frames is not perfectly alligned at the input stream.
I mannually insert incompleted frame from previous chunk to the next chunk.
const size_t remainingBytes = mp3.memory.dataSize - mp3.memory.currentReadPos;
Each chunk started after it with FFFB that indicates next mp3 frame. I checked chunks consistence with whole mp3 buffer after it have been received.But dispite that I have the same gap of silence ahead around 0.05 sec with decoded pcm chunk.
Could you give please some hints on this?