Now that I'm done doing simple id3v2 tags with jid3v2, a small hurdle has come up. Images. Up until now, I've been storing the bytes of frames in byte arrays. When you get to images, which can be 100 kilobytes or more, then you start chewing up RAM with that kind of code.

Images aren't the only frames with this problem. Technically in id3v2 the frames have very high length limits, which are specified in the frame header and differ by id3 version. 2.2 uses three bytes, 2.3 uses four bytes and 2.4 uses four sync-safe bytes. An effective library should be able to handle these limits.

2.2: 3x8 = 24 bits, a range of 0 to 16,777,216
2.3: 4x8 = 32 bits, a range of 0 to 4,294,967,296**
2.4: 4x7 = 28 bits, a range of 0 to 268,435,456

**Note that the tag length is also a syncsafe 4 byte number (28 bits), which is the total length of all of the frames. So a frame with a length over 2^28 bytes isn't possible.

Those are some big maximum frame sizes. The way I see it, I have two options for these large frames. The first is to make a copy of these long frames and store as files somewhere; maybe somewhere in the user's temp directory, maybe a directory that you specify to the library that's in your application's directory. Then if you need to write that frame to a tag, you copy that frame's file over to the new tag. An obvious disadvantage of this approach is that it takes time to copy bytes like this.

The second option is to make a reference to the frame: the file, the starting position (offset) and the length. Then you don't have to copy the data in the frame to a temp directory in between. The disadvantage is that you can't move the source file, or the frame reference points to a missing file and the frame can't be written -- d'oh.

This might make you question the lifecycle of a Tag2 object produced from the jid3rL library. Will it be used right away, or will it have to stay around for a long time? In the case of AudioMan, the data is transferred to another object almost immediately, and the Tag2 is discarded. But as a library writer I don't think I can assume that will always be the case, which seems to make the temp file option a better choice. Thoughts?