If you managed to get though my babbling about big id3v2 frames (not just once, but twice) you might be asking yourself "why?" And that's a great question, because I could be trying to solve the wrong problem.

Tag2 (as well as SimpleTag2) has a method called writeToFile(File). The idea there is that even though most of the time you'll want to write the tag back to the original file sometimes you may want to read a tag from one file, modify it slightly and then write to it another file.

Let's say you keep track of large frames by reference; you keep track of the File, offset and length to find the frame. Then you read the tag on Monday, delete the original file on Tuesday and try to write the tag to another file on Friday. All of those frames-by-reference will be gone because the original file is gone.

But is this such a big deal? The tag still contains a lot of data: all of the frames that are small enough to be parsed to regular Java Objects. You could still write this data on Friday, and maybe tell the user of the library "hey, by the way: everything by reference wasn't written because the file is gone." That's the worst case.

More often though, you'll be writing to the same file the tag was read from. That file will still has all of the frames-by-reference, right? Yeah, probably. Maybe another program deleted one of them, but you can just skip that missing reference now because it's already gone.

Update 12:49: File, offset and length are not good references into a file to find a frame. Frame ordering can change over time, and the position of frames can be bumped slightly if previous frames increase in size. It's impractical to keep track of the offset changes that could happen in other applications.

A better reference is a pointer to the File, and the List of Objects I use as a frames hierarchy key. Then it won't matter if the position of the frame changes within the file, I can find the frame based on the jid3rL frame hierarchy I made up.