Re: [mpg123-users] Looping a single track

[Chris S. <ch...@da...>]

Thanks Thomas.

I pulled my existing code which used mpg123_replace_reader_handle() and
mpg123_open_handle() and reassembled it into a standalone test program
similar to those in doc/examples. I finally got it working when I realised
that I had to set MPG123_FORCE_SEEKABLE *before* the handle was opened, and
also use MPG123_DONE to detect the end of the stream and not to rely on the
value of 'done' returned from mpg123_read() being less than the requested
number as an indication that the stream had finished. For reference,
mpg123_to_wav_replaced_io.c doesn't set MPG123_FORCE_SEEKABLE so calls to
lseek_cb() never happen, which caught me out.

Now I just have to migrate the test program back into my application!

My test program is attached if you're interested to see. Please feel free
to add it to the examples in doc/examples if you feel it would be a useful
API demonstration.

Thanks for the help
Regards
Chis


On Tue, 7 Sept 2021 at 15:01, Thomas Orgis <tho...@or...> wrote:

> 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
>
>
> _______________________________________________
> mpg123-users mailing list
> mpg...@li...
> https://lists.sourceforge.net/lists/listinfo/mpg123-users
>