Padding of ID3v2 Tags

Support
1

I have read in this forum that, by default, Mp3tag pads ID3v2 tags to 2048 bytes.

I wonder if this mean that Mp3tag adds 2048 bytes of padding (extra null bytes), or if it means that it sets the entire tag size (header + frames + padding) to 2048 bytes? I cannot convince myself one way or the other.

Because I had read that Mp3tag pads 2048, I chose that for my LAME encoding, figuring that Florian is pretty wise, so this must be a good padding size. So I have used (in LAME)

V0 --id3v2-only --pad-id3v2-size 2048

After LAME encoding, I check my files with mp3diags, and the ID3v2.3 tag shows padding=2048.

If I subsequently resave my tag in Mp3tag, the padding size reported by mp3diags generally decreases.

So I'm left wondering what Mp3tag is doing with padding.

  1. As asked above, is the target 2048 the padding, or is it the entire tag size?

  2. Does Mp3tag actually remove padding under certain circumstances? If so, why? And can this be controlled by the user?

  3. If Mp3tag is removing padding, could this eventually result in having to rewrite the entire file when I edit the tag in the future? Or can Mp3tag increase the padding again at a later date, to prevent this?

Can someone explain how padding is set when I CREATE a tag in Mp3tag, and how padding is changed when I re-save a tag with Mp3tag?

Many thanks for help on this. My apologies if I have overlooked a write-up on this somewhere. I have done my best to search it out.

2

Hm, is padding such an important topic?
Well, you can check it out for yourself.

  1. Use the notepad text editor and create a textfile with three characters in the first line, e. g. "123".
  2. Save this file with the filename "Test.mp3.txt". Close the Editor.
  3. Rename this file to "Test.mp3" and load it into Mp3tag.
  4. Check the size properties of the file from within Mp3tag resp. by some file manager.
  5. Set the tag-type to write, e. g. ID3v2.4.
  6. Create one tag-field "TEST" with the content "ABC".
  7. Check the size properties of the file from within Mp3tag resp. by some file manager.
    The file should have the size of 2080 bytes.
  8. Use a hex lister to look into the file.
  • At the beginning there is the 10-byte ID3 header.
  • Then follows a TXXX tag-field "TEST" with it's content "ABC".
  • Then follows the padding.
  • At the end of the file there are the three bytes "123", with their meaning of musical data in this test case.
    The first ten bytes in hex are: "49 44 33 04 00 00 00 00 10 13"
    The last four bytes (only 7-bit used) of the ID3 header contain the length of the following data part.
    In this case it is ...
    0 = d0
    0 = d0
    x10 = d16 * d128 = d2048
    x13 = d19
    ... 2067 bytes.

2080 (filesize) - 10 (ID3 header) - 3 (musical data) = 2067 (tag size)

It looks like the tag-field "TEST" with the content "ABC" (19 bytes) has been padded with additionally 2048 bytes, giving an entire tag size, including the ID3 header, of 2077 bytes.

DD.20131125.1245.CET

3

The whole idea behind padding within a tag is to allow the data within the tag to expand and contract without necessitating a rewrite of the entire file. If you later add or remove some fields or data, it's much faster to save the update.

When Mp3tag is able to write the data you specify into the existing tag it will use the padding space, and that space will grow or shrink, as needed. The overall file size will remain the same. When you specify so much new data that the padding is insufficient, Mp3tag will be forced to rewrite the file, and will write a tag with 2048 bytes of padding. It will do the same if you write a new ID3v2 tag to a file that previously had none.

I'm pretty certain 2048 is the padding size added, not the overall ID3v2 tag size. It wouldn't make much sense otherwise. If Mp3tag were forced to rewrite the file to expand the tag and that tag was, say, 2040 bytes, it would only leave 8 bytes of room for future edits. It would hardly be worthwhile. If mp3diags can tell you the size of the padding, then this should be very easy to test for yourself. Create an Mp3 file with no tagging at all, open it in Mp3tag and add an ID3v2 tag.

There's nothing at all special about 2048 bytes. It just gives you a lot of room to grow the metadata at a later date.

4

I think you are right, DetlevD. That is probably the question I should have asked first.

Here is why I brought up the issue:

Over the past several years, I got into ripping (with EAC) my rather extensive CD collection to WAV files, followed by compression with LAME, tagging with Mp3tag, and leveling with mp3gain. Very recently, as I migrated to Linux, I had problems getting EAC to behave well under WINE, and I settled on RubyRipper as the best alternative. For some reason, it takes RubyRipper much, much longer to generate a WAV file than it does to produce a flac file along with an mp3 file. So I started ripping directly to flac + mp3. (The flac is for archiving and home play, the mp3 for on the road.)

Now, as I really studied the codec options, I learned a bit about this "tag padding" business. Obviously I have a lot more to learn, and so I am concerned.

When I rip to WAV, compress to mp3, and THEN tag with Mp3tag, it sounds like I must always be re-writing the entire file, because LAME does zero padding by default. I am assuming that re-writing the file is undesirable because (1) it introduces the slight chance of a copy error; (2) it could contribute file fragmentation; and (3) a large batch retagging could get time consuming.

When I backup my audio files, I use rsync, to verify that the copies are accurate. When I re-write an audio file due to a tagging update, I have no idea what sort of verification might be going on (probably none). This is why I think padding is important. But I am truly a noob in this territory, and am very grateful for your comments and suggestions.

It looks like FLAC adds 8k tag padding by default (and more for larger files). And both LAME and FLAC allow for user-specified amounts of padding.

That's what I thought Mp3tag does, too. Yet, when I slightly modify and re-save a tag in Mp3tag, I seem to get considerably less than that amount of padding -- at least as listed in mp3diags. This may be a matter of semantics -- what does mp3diags mean by "padding."

So, I've got more homework to do. I plan to try a bunch of tests with both mp3 and flac files, with tags padded to different degrees. Then I will slightly modify and re-save the tags in Mp3tag, to see what happens to the amount of padding. No time to do this for a couple of days, as I have house guests.

Maybe I am making more of this than it deserves. However, I generally hate to copy/rewrite my precious files unless I have to. And when I do, I like to know I can verify the copy.

Thanks to both DetlevD and JJ Johnson for taking time to improve my perspective. You have both helped me greatly in the past, and you make this forum a wonderful resource for those of us with less expertise.

5

Only #3, IMO. It's much slower and not necessarily only when doing large batches of updates.

Yeah, you still don't get it. When able to, Mp3tag uses the existing padding as a place into which it can expand the metadata. The overall tag size and overall file size remain the same. The amount of padding in the ID3v2 tag decreases when you add data, and it increases when you remove data. ONLY when Mp3tag must rewrite the file will it do so, and only then will it add 2048 bytes of padding.

Sounds like you need to better understand what you ripper is doing and figure out if you can specify additional command line parameters, so that you can have it tell LAME to add padding at the time of ripping.


A better alternative to ripping to two formats may be to use a script that mirrors your FLAC library in Mp3. This is what I do. For one, it avoids the slowdown during ripping that Mp3 encoding introduces. For Linux, there's this one:

<a href="http://projects.robinbowes.com/flac2mp3/trac" target="_blank">http://projects.robinbowes.com/flac2mp3/trac</a>
6

Actually, that is my understanding. What surprised me was that, when I re-saved a tag in Mp3tag, it seemed to appreciably shrink the remaining padding (from 2048 to something like 667), even though I didn't add any metadata. I did, however, likely change the format of the tag (from v2.4 to v2.3). As I said, I need to go back and verify exactly what I did that may have caused the padding to shrink by that much. Please forgive my lack of clarity in my previous posts.

Right you are! I would definitely like to better understand what RubyRipper is doing. Unfortunately, the documentation does not go into any detail, nor does the GUI provide controls that suggest what is going on. So I am trying to reverse engineer what it is doing by trial and error. However, as I said in my initial post, I am using LAME options to add padding to my mp3 files as they are created, using

V0 --id3v2-only --pad-id3v2-size 2048

This seems to work rather well. When I was letting RubyRipper control the padding, it was defaulting to zero.

Thanks very much for the tip on using a script to mirror the FLAC library to mp3. Although the encoding appears to go very quickly as part of the ripping process, I'd still like to see how this other approach might work. I wonder if I could control the mp3 tag padding by this mirroring method. :wink:

As always, I am very grateful for your support. Your posts on this topic have been very helpful in confirming some things I was shaky on, and in pointing out some issues I hadn't even considered.

Thank you!