AudioFormatReader::read usage and Windows Media Audio format

Is it acceptable to call AudioFormatReader::read multiple subsequent times to iteratively load an audio file, such as in a progress thread?  Or must it be called on the entire file at once?

The reason I ask is because, in the readSamples function in the WMAudioReader class, there is this bit of code:

                    if (firstLoop && readBufferStart < startSampleInFile)
                        bufferStart += stride * (int) (startSampleInFile - readBufferStart);
                        if (bufferStart > bufferEnd)
                            bufferStart = bufferEnd;

When I try to read certain .mp3s, I get a glitch in the audio data when this statement's conditions are met.  So I'm trying to understand what "firstLoop" means.  When I comment out this block, I don't get a glitch.

Anyone else experienced this?

Actually, I narrowed this down even further.

In BufferingAudioSource::readNextBufferChunk(), there is a line that says:

const int maxChunkSize = 2048;

Is there a specific reason that the maxChunkSize has to be this value?  My audio glitch was happening because I was using a buffer size of 1024.  But if I use 2048, the glitch doesn't happen.

To reproduce the issue, try modifying that line of code to 1024 and then running the FilePlayback demo in the JuceDemo with the attached .mp3 file.  (I renamed the extension so I could upload it).

Obviously it's fine to call read() multiple times, BUT the MP3 reader (and possibly other readers for compressed formats) is not very good at seeking, so if you ask it to jump around, then it may return blocks that don't line up perfectly with the results that it returned previously. But it should be ok as long as you're careful to call it such that the start of the next block that you ask it to read is the same as the end of the last one.

Ok, thanks.  But, after more testing, I am certain that there is a bug in the Windows Media Audio code that I referenced above.

Just run the Juce Demo (stock; no modifications), click on the File Playback demo, and choose the .mp3 file that I attached (rename the .txt extension to .mp3).  There is a click/pop in the audio a few tenths of a second after the beginning.

Ah, sorry, I misread your oringal post. Thanks - I'll try to figure out what's going on in there!

FYI I think this should be ok now if you want to try again. The WMA codecs are a bit strange though, they don't seem to do a very good job of seeking or reporting their postion correctly, but I've managed to bodge things so that it at least keeps the blocks continguous.

That seemed to fix it.