[juce_MP3AudioFormat]: readVBRHeader() should account for the offset returned by scanForNextFrameHeader()

General JUCE discussion
1

Hi there,

I’ve recently received reports that some users are unable to read certain MP3 files. It appears that some online music platforms insert proprietary data between the ID3 metadata and the first MPEG audio frame, which can trip up juce_MP3AudioFormat.

JUCE already accounts for this by locating the first valid MPEG frame:

auto nextFrameOffset = scanForNextFrameHeader (false);

However, this offset is not used when reading the VBR header. I believe readVBRHeader() should take the discovered offset into account:

void readVBRHeader (int frameOffset)
{
    auto oldPos = stream.getPosition();
    stream.setPosition (oldPos + frameOffset);

    uint8 xing[194];
    stream.read (xing, sizeof (xing));

    vbrHeaderFound = vbrTagData.read (xing);

    if (vbrHeaderFound)
    {
        numFrames = (int) vbrTagData.frames;
        oldPos += frameOffset + jmax (vbrTagData.headersize, 1);
    }

    stream.setPosition (oldPos);
}

That said, I’m not an expert in MP3 internals, so I may be overlooking something. This change fixes the affected files in my testing, but I’d appreciate it if someone from the JUCE team could confirm whether this is the correct approach.

2

Thank you for reporting this issue. A fix is now out on develop

1 Like