* Rob Leslie (rob@mars.org) wrote:
Joshua Haberman wrote:
It seems that when you pass the decoder data from the input callback, it tries to synthesize everything you give it. If the end of the buffer you passed ends in the middle of a frame, you get seams. Passing all the data to the decoder at once solves the problem, but that's not practical.
As far as I can see, you can't get any metainformation (like the size of each frame) until you pass it data. Once you pass it data, you've probably misaligned the frame and produced garbage. What's the proper way to handle this situation?
Each time you refill your buffer, you need to preserve the data in your existing buffer from stream.next_frame to the end.
This usually amounts to calling memmove() on this unconsumed portion of the buffer and appending new data after it, before calling mad_stream_buffer().
Wonderful, that took care of the seaming problem! How can I determine the optimal buffer size to keep memmove()ing to a minimum? Should I hard-code a size that corresponds with a common mp3 frame size, or should I try to determine it a runtime?
It seems like the worst case would be having the buffer length just short of two frames -- then you'd copy almost all of the second frame in each run. Best case would be three or four frames at once...?
Joshua