This comment seems to imply that, even with the bit reservoir disabled, I can't simply stitch the MP3 chunks together?

Correct. Other than the first frame in the stream, you can't fully decode any MP3 frame without information from the previous frame. You need to use a decoder that can handle partially decoding the MP3 as it arrives.

You don't need to disable the bit reservoir.

Two possible solutions:

1. Create mp3's with the --nores option in LAME,
(disabling the bit reservoir and reducing quality somewhat),
these mp3 files can be simply cut and pasted on frame boundaries.

1. I'm using FFMPEG as a decoder - doesn't it support partial chunks?

2. What about this part from LAME's FAQ?

It does. Unfortunately, I'm not familiar with the API, so I couldn't tell you what you might need to do differently to make it decode your MP3 correctly.

That refers to cutting apart the MP3 file and stitching the frames together in a different order - or even stitching together frames from different files. You're not doing that, so you can use the bit reservoir.

In my particular case, I need to decode each chunk to PCM data, one chunk at a time, so that would never work, right?

I believe what you mean when you say: "You need to use a decoder that can handle partially decoding the MP3 as it arrives.", is that the decoder would receive a stream of the MP3 data and thus be able to gather the right data from different frames (N, N+1, N+2, or whatever frame it needs) (which might not be available if solo chunks are provided to the decoder).

Why would cutting apart an MP3 file and stitching the frames together in a different order be possible, but not in the right order?

You're close. It's actually using earlier frames (N, N-1, N-2, etc.) so the decoder should have access to all of them even if you're only giving it one frame at a time.

ffmpeg -i chunk1.mp3 ... output1.wav

ffmpeg -i chunk2.mp3 ... output2.wav

With the bit reservoir disabled, both should be possible. With the bit reservoir enabled, you can only decode the frames in the right order.

Correct. Other than the first frame in the stream, you can't fully decode any MP3 frame without information from the previous frame. You need to use a decoder that can handle partially decoding the MP3 as it arrives.

That refers to cutting apart the MP3 file and stitching the frames together in a different order - or even stitching together frames from different files. You're not doing that, so you can use the bit reservoir.

But how can the decoder have access to all of the frames if I'm giving it one frame at a time?

Either by feeding it frames through a pipe or by using the API directly. Right now, you're feeding it a separate file for each frame, so it doesn't know that they're supposed to all be part of a single stream.

I have some limitations with the tech I'm using (FFMPEG WASM → FFMPEG for the browser), which doesn't seem to support streams.

But from what I can intuit from our conversation here (as I said in my previous reply, I'm still a bit confused), even if I disable the bit reservoir (as an attempt to make each frame independent), the frames are not 100% independent (maybe because of the MDCT coefficients stuff?), thus I can't decode frames and stitch them together 🥹

That's correct.

Can you use different tech? Like this, for example.

Do you have some evidence that this lib supports streams? In other words, does this lib support piping audio data?

Where should I start exploring - I'm not so familiar with those low-level libs. Should I start exploring libavcodec → lame? Or libavformat → lame?

Quote from: maxime on 2023-01-11 21:51:35

Do you have some evidence that this lib supports streams? In other words, does this lib support piping audio data?

It does! You'll feed the decoder your downloaded MP3 frame using avcodec_send_packet() and then repeatedly call avcodec_receive_frame() to get decoded audio until the decoder tells you it needs the next MP3 frame. You can do this as you download the MP3 frames.

Quote from: maxime on 2023-01-11 21:51:35

Where should I start exploring - I'm not so familiar with those low-level libs. Should I start exploring libavcodec → lame? Or libavformat → lame?

This example might be helpful. I think you can do everything with just libavcodec; there's no container for libavformat to demux.

I believe the problem is in the difference between "sticking two frames together and decode them" versus "decoding one frame, then decode the other frame and then stick the result together".

Also, decoding individually the frames means that the decoder always start from a silence start, which would be an incorrect assumption. (gapless playback works because a compliant decoder has the lametag information of samples to skip)

In case of two frames created from a consecutive stream, the second frame would not need to skip the initial part because that part is already audio.

In other words. If your application can send the mp3 already concatenated to a decoder, rather than sending individually each frame as a separate audio, then you should be done.

Also, I am assuming that you actually don't have any additional frame of information, like a frame with lametag at the beginning. That frame would then be considered an audio frame is you stick it to a previous frame.