CODEWITHSUNDEEP
c++parsingffmpegmp3id3
PookyFan
PookyFan

Reputation: 840

Proper reading of MP3 file disrupted by ID3 tags

My semestral project is due this Thursday and I have major problem with reading MP3 file (the project is about sound analysis, don't ask my what exactly is it about and why I'm doing it so late).

First, I read first 10 bytes to check for ID3 tags. If they're present, I'll just skip to the first MP3 header - or at least that's the big idea. Here is how I count ID3 tag size:

if (inbuf[0] == 'I' && inbuf[1] == 'D' && inbuf[2] == '3') //inbuf contains first 10 bytes from file
{
    int size = inbuf[3] * 2097152 + inbuf[4] * 16384 + inbuf[5] * 128 + inbuf[6]; //Will change to binary shifts later
    //Do something else with it - skip rest of ID3 tags etc
}

It works ok for files without ID3 tags and for some files with them, but for some other files ffmpeg (which I use for decoding) returns "no header" error, which means it didn't catch MP3 header correctly. I know that since if I remove ID3 from that .mp3 file (with Winamp for example), no errors occur. The conclusion is that size count algorithm isn't always valid.

So the question is: how do I get to know how big exactly is entire ID3 part of the .mp3 file (all possible tags, album picture and whatever)? I'm looking for it everywhere but I just keep finding this algorithm I posted above. Sometimes also something about some 10 bytes footer I need to take into account, but it seems it frequently gets more than 10 bytes for it to eventually catch proper MP3 frame.

Upvotes: 0

Views: 3127

Answers (2)

Alexander Dyagilev
Alexander Dyagilev

Reputation: 1425

bool LameDecoder::skipDataIfRequired()
{
    auto data = m_file.read(3);
    Q_ASSERT(data.size() == 3);
    if (data.size() != 3)
        return false;
    if (memcmp(data.constData(), "ID3", 3))
    {
        m_file.seek(0);
        return true;
    }

    // ID3v2 tag is detected; skip it

    m_file.seek(3+2+1);
    data = m_file.read(4);
    if (data.size() != 4)
        return false;

    qint32 size = (data[0] << (7*3)) | (data[1] << (7*2)) |
            (data[2] << 7) | data[3];

    m_file.seek(3+2+1+4+size);

    return true;
}

Upvotes: 2

PeterCo
PeterCo

Reputation: 961

The size of an ID3v1 Tag is always fixed 128 Bytes.

I will find the following description

If you one sum the the size of all these fields we see that 30+30+30+4+30+1 equals 125 bytes and not 128 bytes. The missing three bytes can be found at the very beginning of the tag, before the song title. These three bytes are always "TAG" and is the identification that this is indeed a ID3 tag. The easiest way to find a ID3v1/1.1 tag is to look for the word "TAG" 128 bytes from the end of a file.

Source: http://id3.org/ID3v1

There is another version, called ID3v2:

One of the design goals were that the ID3v2 should be very flexible and expandable... Since each frame can be 16MB and the entire tag can be 256MB you'll probably never again be in the same situation as when you tried to write a useful comment in the old ID3 being limited to 30 characters.

This ID3v2 always starts at the begin of an audio file, as you can read here: http://id3.org/ID3v2Easy

ID3v2/file identifier   "ID3"
ID3v2 version           $03 00
ID3v2 flags             %abc00000
ID3v2 size              4 * %0xxxxxxx

The ID3v2 tag size is encoded with four bytes where the most significant bit (bit 7) is set to zero in every byte, making a total of 28 bits. The zeroed bits are ignored, so a 257 bytes long tag is represented as $00 00 02 01.

Upvotes: 2

Related Questions