#235 mpg123_read written amount of memory

[Daniele Ghisi]

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

[Thomas Orgis]

Am Wed, 29 Jun 2016 12:12:06 +0000
schrieb "Daniele Ghisi"

Hi, this is more a question than a bug.

Hm, so it would be better phrased as one (via the user mailing list,
p.ex.). But anyway …

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?

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?

[Daniele Ghisi]

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

[Thomas Orgis]

Am Wed, 29 Jun 2016 23:43:24 +0000
schrieb "Daniele Ghisi":

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.

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?

[Daniele Ghisi]

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 ;)

void playmp3_perform64(t_playmp3 *x, t_object *dsp64, double **ins, long numins, double **outs, long numouts, long sampleframes, long flags, void *userparam)
{
    // INITIALIZATION STUFF HERE 

    // read n bytes from mh handler and puts them into the x->buffer
    // 4 bytes for each sample (encoding is 32-bit float)
    // memory_vector defaults to 4096 (2 channels * 4 bytes * 512 buffer size)
    if (!x->paused && (res = mpg123_read(x->mh, x->buffer, memory_vector, &done)) == MPG123_OK) {

#ifdef EARS_PLAYMP3_SAMPLEACCURATELOOPING // < this is defined
        if (x->loop && done < memory_vector) {
            // I NEVER GET HERE, and x->loop is set to true.
            // Printing the values of memo
        }
#endif

            // COPY SAMPLES IN MY ARRAY

    } else {

        if (res == MPG123_DONE && x->need_send_bang) {
            // File has ended
            if (x->loop) { // looping
                mpg123_seek(x->mh, x->seek_to, SEEK_SET);
            } else { // sending out bang
                // notify end
            }
        }

        // FILL MY ARRAY WITH 0's
    }

}

[Thomas Orgis]

Am Thu, 30 Jun 2016 22:34:18 +0000
schrieb "Daniele Ghisi"

if (!x->paused && (res = mpg123_read(x->mh, x->buffer, memory_vector, &done)) == MPG123_OK) {

ifdef EARS_PLAYMP3_SAMPLEACCURATELOOPING // < this is defined

    if (x->loop && done < memory_vector) {
        // I NEVER GET HERE, and x->loop is set to true.

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).

    if (res == MPG123_DONE && x->need_send_bang) {

I'd expect the short done count here.

Sorry if that seems too simplisitc. I should be sleeping since 3 hours
at least.

[Daniele Ghisi]

Thank you, this makes perfect sense, and works like a charm!!!
d