I like how flexible LAME is when it comes to writing ID3v2 tags, but there's one command I find curious: --pad-id3v2

The docs say it will "pad version 2 tag with extra 128 bytes," which makes sense; all ID3v2 editors I've seen pad their tags so programs don't have to rewrite tags everytime something new is added, but my question is, why only a measly 128 bytes? Adding just a few more fields is liable to fill the padded space up. Most editors I've seen are able to tag 2 to 4 kilobytes or more, and even allow the user to select an integer of kilobytes to pad when writing.

My question is, could that functionality be built into LAME, or at least make the --pad-id3v2 preset pad more than 128 bytes?

My thought is that 128 bytes is 128 characters to play with. Your average song title is likely to be less than 50 characters. Artist and Album around 10 to 20 each. That's only a little over half the available pad. Remember that 4k is over 4000 characters. That's highly unlikely except perhaps if you're including lyrics or extensive comments. For most uses, "128 bytes is enough"

You could probably change the pad value in the source. Do you expect to need more than 128 bytes of padding? It's unlikely in any event that the time required to rewrite the whole file will be all that noticeable anyway.

It does seem odd that in a file that will probably be several megabytes, that you would be so stingy when adding padding for tags.

Let's have one thousand MP3's (a small collection, in all regards).
Let's have 4KB of padding instead of 128Bytes.
Let's be the average song file 4MB.

Having a 4KB padding implies having the space for exactly one less song, gaining absolutely nothing (and this is the point).

Let me remind that padding is not the size of the tag, but the size left empty after the tag, for future expansion. The only time where one will use more than 128bytes is, as said, when adding lyrics, or when adding album art.

In the first case, 4kb may be enough. In the second case, not even 4KB are enough (and note that lame does have a switch for adding album art at encoding time)

Hmm...

How often have people encoded at -V2 even though they could not distinguish -V3 from the original, and even though they will be able to fit 5% or 10% fewer songs, they feel it is worth it just in case -V2 is ever needed?

Then how often has someone been upset because they were only able to fit 999 songs when they wanted 1000, but that was the price they paid for having extra padding in their ID3V2 tags?

It's like the argument about which lossless codec to use and what settings, but the difference is a full order of magnitude less.

Even when i've remarked it, you've missed it.
A -V 2 encoded file is not the same as a -V 3 encoded file. A file with more padding is the same as another file with less padding.

Actually, it's far less than 128 characters, because each field's identifier alone takes up 11 bytes each. (Looking at any LAME-tagged file in a hex editor shows that any given field is NAME (4 bytes)+3 empty bytes+1 character whose purpose I don't know+3 empty bytes+field data). So if I were to add, say, 4 more fields after encoding, I would really only have 128-44=84 bytes for them, which might or might be enough, but is far less than 128.


You and most others in the thread seem to have jumped on my suggestion of 4kb. I agree that's probably excessive (but then one wonders why so many tag editors pad that much by default), and I would be happy with just 1 kb of padding.


I would if I could, but I'm not a programmer and wouldn't know where to find it in the source or how to compile it if I did.


If that's the case, what is the purpose of padding ID3v2 tags at all? But in any case, it is absolutely noticeable when a tag editor (I've tried several) has to rewrite a whole album's tags vs. just filling in padded space.

That assumes that you are actually putting in additional tags. If you are just increasing existing tags then it really is 128 characters, unless they are utf-encoded.

Of course I gain something; the ability to add tag data after encoding that either LAME is unable to add or which I find out much later, without some other program having to rewrite the whole file.

Again, I agree that 4 kb is probably excessive, but why not just 1 kb then? It seems odd that when every other tag editor I've used allows padding at least 1 kb, LAME would insist that 128 bytes is enough--and depending how how many tags one has LAME write at the time of encoding, it very well might not be.


Or if adding several text fields, such as Album Artist, Composer, Conductor, Disc number, Encoder Settings, and Artist Website. Again, remember that each field's identifier alone is 11 bytes, so if I waned to add all of those, I would only have 62 bytes to contain all the data.


Yes it would, so why not add the functionality?


Well, I don't intend to embed album art anyway. My main concerns are adding extended text information, like I described above. 128 bytes is not enough for more than a handful of tags.

Also, it seems to me that the 128-byte limit assumes that the user uses LAME's tagging parameters to add the main tags (artist, album, title, genre, etc) at encoding time. While this is true in my case (I use EAC+LAME), it might not be true for everyone. Conceivably someone might want to write an empty padded ID3v2 tag and then add all the info later using another program. If so, 128 bytes is only enough for a handful of fields.

I like the idea of 'zero-overhead rule': "What you don't use, you don't pay for". Of course, 4 kb is just 1 cluster in NTFS filesystem, but...

Well, my intended usage is to put in additional tags. I don't know why one would add text to existing tags.

LAME 3.99 will have a new switch "--pad-id3v2-size <value>" which allows you to add upto 128000 padding bytes, you can use that instead of "--pad-id3v2".

Sweet! Thanks for the heads up. 125kb should be more than enough for any ID3v2 tag. Out of curiosity was that already planned for 3.99, or did my suggestion prompt its inclusion?

The latter. It may already come a little bit earlier with bug fix release 3.98.1 together with a sloppier ID3v1 genre matching.

That's great news robert.