mpg123_read written amount of memory
Brought to you by:
sobukus
Hi, this is more a question than a bug.
I'm using mpg123_read, and I'm experiencing the fact that whenever the function returns MPG123_OK, the written memory (stored in last argument "done") always corresponds exactly to the requested outmemsize. I'm using mpg123_read repeatedly and my outmemsize is always a certain fixed amount.
This is consistently happening on multiple files, and it looks of course nice, but I wonder what happens at the very end of each file. I would expect the last chunk of data to have a done < outmemsize. Am I wrong?
What am I missing?
I'd need this for sample-accurate looping - or is there any other way to achieve it?
Thanks a lot,
Daniele
Am Wed, 29 Jun 2016 12:12:06 +0000
schrieb "Daniele Ghisi"
Hm, so it would be better phrased as one (via the user mailing list,
p.ex.). But anyway …
The very last chunk should be partially filled, unless the MPEG data
happens to be a multiple of your buffer size. Especially with gapless
cutting, there can be any number of decoded bytes less than the
outmemsize.
Sure that it's always full buffers for you up to the end?
Hi, and thanks for your quick answer.
Yes, I am positive - that's why I thought it could be a bug. I'm constantly asking for 2048 bytes, and I am ALWAYS getting 2048 bytes, even at the end of the file. Same thing if I use 4096 bytes. This sounds weird to me as well.
I am using MPG123_SEEKBUFFER | MPG123_GAPLESS | MPG123_SKIP_ID3V2 as flags. I've tried to delete some of these flags, but nothing changes. Could it be some settings I have to change? Is there something I might try?
Thanks,
Daniele
Am Wed, 29 Jun 2016 23:43:24 +0000
schrieb "Daniele Ghisi":
Do you really continue until you get the MPG123_DONE return value? Can
you give a small self-contained C program that shows how you use
mpg123? Is the total count of bytes the same with buffer size 2048 and
1748?
Hi,
yes I do continue until MPG123_DONE. I'm trying to use the library to build an external object for Max (an environment for real-time audio treatments, among other things). Here's the skeleton of my "perform" function, which is called once for every audio vector to process. If you spot anything weird, or if you have any advice at all, that would be great ;)
Am Thu, 30 Jun 2016 22:34:18 +0000
schrieb "Daniele Ghisi"
Sure, because when there is not enough data to return (done <
memory_vector), you won't get MPG123_OK, but instead MPG123_DONE (or
MPG123_NEED_MORE, depending on input method).
I'd expect the short done count here.
Sorry if that seems too simplisitc. I should be sleeping since 3 hours
at least.
Thank you, this makes perfect sense, and works like a charm!!!
d