Hello, For non-mmap'ed input implementations, I have encountered a situation where due to a truncated last frame, an infinite loop occurs.
Where mad_header_decode() returning MAD_ERROR_BUFLEN is interpreted as "need more input", my input caching routine continues to return the unconsumed partial frame. mad_header_decode() says that's not enough and the process just goes on.
The complication I have here is my input routine is a random access input cache routine and doesn't know an EOF has truly occurred until input data is requested beyond the end of file. Thus seeking N times to a partial last frame (or any other frame) could happen.
One ugly hack I have found to avoid this is to increase the 8 byte zero pad sufficiently to satisfy mad_header_decode()'s internal buffer length validation. Whereupon an attempt is made to seek beyond the input length and an EOF can be detected. Another approach is to detect two MAD_ERROR_BUFLEN occurrences at the same address without any other intervening repositioning of the input. The latter is arguably more safe, yet if mad_header_decode() had some way to indicate how much input it was expecting for the current frame, a cleaner solution is possible. This calculation of N bytes exists in the routine. Stuffing this into a new stream structure member would be one possibility..
Any suggestions?
Thanks,
-john