search

pschatzmann / arduino-libhelix

A simple MP3 and AAC Decoder (not only) for Arduino based on libhelix
GNU General Public License v3.0
72 stars 22 forks source link

Misleading log output #6

Closed stevstrong closed 7 months ago

stevstrong commented 7 months ago

Hello, I am using the output_mp3.ino example on F411 discovery board and I have set the LOG level to debug. A portion of the output is this:

libhelix - synchronizeFrame
libhelix - -> frameRange -> 0 - 82
libhelix - -> we are at beginning of sync word
libhelix - decode 82
libhelix - -> bytesLeft 1600 -> 1183  = 417 
libhelix - -> End of frame (82) vs end of decoding (417)
libhelix - => provideResult: 2304

In particular, the line specifying the end of frame (82) and end of decoding (417). Could you please explain why is there a difference?

I know that the previous frame was 417 byte long, but does this mean that there will be more bytes used for decoding this particular frame than the size of this frame (82 bytes)?

I have studied the code in function decode inMP3DecoderHelix.h, but I really don't understand the meaning of the variable bytesLeft from which the value of decoded is calculated (the vale corresponding to the printed "end of decoding"). I mean why needs the decoder to handle how many bytes are left in the buffer? It should not be its task, but of the layer above.

pschatzmann commented 7 months ago

If I remember right the decoder grabs as much as is able to process and reports back how may bytes it has processed. In my logic I just make sure that if I submit some data to decode, I have at least one valid frame. From the reported processed end position, I know how many data I can remove from the buffer.

ps. I admit that the implementation is a bit messy and I would do it differently today because I could use functionality from the AudioTools that were just not available yet, when this has been implemented.

stevstrong commented 7 months ago

Sorry to be picky, I just want to understand why the decoder could use for decoding more bytes than specified in the current frame.

I have read about bit reservoir, and I can see that the info about bit reservoir is only available for AAC (ADIF bufferFull), and is not defined for MP3. I also see here some handling: https://github.com/pschatzmann/arduino-libhelix/blob/27d09c34bd7edbaa1c53edf61fcd9bcbef5af523/src/libhelix-mp3/mp3dec.c#L339-L392 but there the bytesLeft calculation is mixed somehow with the available/used bytes from the mp3DecInfo->mainBuf, which has normally nothing to do with the read bytes from the current frame of the stream. So I really have doubt about the meaning of this variable.

pschatzmann commented 7 months ago

bytesLeft is the total amount of available memory in the buffer that can be used for decoding. But I am confused: your code has nothing to do with the logic of my library! My MP3DecoderHelix.h has only 189 line of code...

stevstrong commented 7 months ago

The link I posted points tomp3dec.c from libhelix-mp3 subfolder, not MP3DecoderHelix.h ;)

pschatzmann commented 7 months ago

Well, as I said - that code is not from me so I am not commenting on this. I am just a user of libhelix and honestly don't bother about the implementation as long as it is working...