Re: Is it possible to stitch MP3 frames together?
Reply #6 – 2023-01-11 19:11:17
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. But how can the decoder have access to all of the frames if I'm giving it one frame at a time? This assumes that the decoder keeps the previous frames in memory, right? So what I said about needing to feed a stream of data to FFMPEG seems to be true. For example, if I executed a ffmpeg command on one chunk ffmpeg -i chunk1.mp3 ... output1.wav and then another command on another chunk ffmpeg -i chunk2.mp3 ... output2.wav ffmpeg doesn't keep the previous chunk in memory for the next command. This is basically what I'm doing right now. I believe what I would need to do instead is continuously stream the mp3 to FFMPEG. Otherwise, If I just decode the chunks independently, it won't work right? With the bit reservoir disabled, both should be possible. With the bit reservoir enabled, you can only decode the frames in the right order. I'm trying to understand what you mean here, because you also said 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. And this 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. So let me clarify this: Is it possible to stitch MP3 frames together so long as we disable the bit reservoir (as seemed to be descibed in the LAME doc I pointed out earlier)? 🤔 Thanks again 🙏