Re: [mpg123-users] Looping a single track

[Thomas O. <tho...@or...>]

Am Tue, 7 Sep 2021 13:36:31 +0100
schrieb Chris Smith <ch...@da...>: 

> I've tried replacing the read handler, using open_handle mpg123_read, and
> tried using feedseek even though I'm not calling mpg123_feed, but I
> inevitably end up with a "Warning: Encountered more data after announced
> end of track (frame 582/582). Frankenstein!"

This has less to do with your usage, but with the MPEG file containing
an Info frame that tells the decoder how much data to expect. Libmpg123
should continue decoding, but you're confusing it a bit. You got some
options (without having looked at your example yet, sorry … I'm just
quickly whipping up a reply, being busy with other stuff) please point
out where I am going astray):

You could cut out this info frame (tell libmpg123 to ignore it), but
that would counter your goal of having seamless looping. That same info
frame contains information to cut out samples that would introduce
artificial gaps.

> I need to start from scratch I think. So to simplify things for this post
> and because mpg123_feed feels like the right thing to do,

Usually, no. If you can wrap your head around function pointers, having
your own callback reader functions is much easier to code and follow.

I think you should just not try to trick libmpg123 into feeding an
endless ringbuffer of data. Configure your handle read/seek callbacks
that access the memory, use mpg123_open_handle() to open the track.
Then, simply seek back to 0 on MPG123_DONE and continue decoding
(filling up your output buffer).

This way, the gapless decoding is still handled properly
(encoder/decoder delay and padding being cut) and your loop can play
seamlessly.

The next best thing, if you don't care about gapless decoding, would be
to simply implement your read callback with a ringbuffer to keep
feeding MPEG frames and tell libmpg123 to ignore the info frame
(flag MPG123_IGNORE_INFOFRAME). Downside here is that you'll have an
endless position counter in libmpg123 that might and some distant time
overflow.

The best bet would be not to fool the decoder and just let it seek back
to 0 on end.


Alrighty then,

Thomas