I saw something that concerned me a little bit wrt hashing in jEmplode. I ran my MP3's through MoodLogic which fixed all my tags. One of the things I noticed is that some MP3's didn't calculate to the same hash anymore. Now remember that my method for calculating MP3's is to pop off the ID3 tags and hash only on the MP3 data. It turns out that in some cases, the MP3 data had one extra byte on the end. Does anyone know if the MP3 format specifies some sort of padding where it's trying to keep the frame data to a multiple of some fixed offset from the start of the file or something? That really sucks if that is the case.

Does anyone know if the MP3 format specifies some sort of padding where it's trying to keep the frame data to a multiple of some fixed offset from the start of the file or something?

No. The size of an MP3 frame depends only on the bitrate and layer and other fields of the header. There is no leeway for padding. If two applications disagree about the size, one of them has a bug (but note that Lame, for instance, adds an "Oooh look encoded with Lame" block after the last frame, which doesn't begin with a frame header so is interpreted by players as loss of streaming).

Peter

note that Lame, for instance, adds an "Oooh look encoded with Lame" block after the last frame

Which thought was pretty lame

i would disagree. it let's software like encspot to identify the "superior" codec.

I'm sure one of the fields in the header is called "padding", which I thought allowed frames that could encode to 1 byte shorter than usual to be padded to the length of the other frames. ISTR having an argument with Mike about it, but can't remember the outcome

Hugo

I had to work around this "one byte padding" thingamajig in my GapKiller code, so I'm intimately familiar with it. It's per-frame, so each and every frame has the possibility of having the padding byte, I don't think it has anything to do with the end of the file. This Guy has a very detailed and easy to understand description of the frame headers and how the padding byte works into it.

Edit: Mike, I just re-read what you were saying, and you were talking frame-by-frame not about the end of the file. So the header spec I just linked should in fact answer your question quite well.

ISTR having an argument with Mike about it, but can't remember the

Said argument didn't take place over a pint or three, did it?