So to summarize an earlier post about big frame sizes: id3v2 tags can be up to 256MB long, so technically speaking an id3v2 tag could have a single frame that's also 256MB long.

You may have read the comments on a post I wrote early in in jid3rL development. I explained that when a tag was bigger than the previous one, the whole file including the music had to be rewritten because of the way that file systems layed out files. To counter this, most tags are padded with zeros to allow a tag with more data to fit without needing to rewrite the whole file over again.

In the case of large frames, rewriting a file could turn into a hard drive space problem. If a tag is too long to fit over the old tag for a file F, I do the following.

1. create a temporary file T
2. write the new tag to T
3. skip the size of the old tag in F and then write the rest of F to T
4. delete F
5. rename T to F

So just before step 4, I have two copies of the file -- F with the old tag and T with the new tag. If the tags are 256MB then that's at least 512MB, nevermind the size of the music. :) If I use the first approach I explained yesterday where I copy frame data to a temp file so I always have it, then that's another 256MB I need.

Using this extreme example you can see the jid3rL library will need to set a limit on the maximum supported frame size, after which the library could just refuse to modify the file. It could also just ignore gigantic frames and not rewrite them the next time the tag is written. Hard to say ...

This makes three different types of frame storage:

1. If the frame is small enough (ie. size < 1024 kilobytes), its information is parsed and stored as Java Objects.
2. If the frame is large (ie. 1024 kilobytes < size < 1 Megabyte), the frame is stored as a temp file or a pointer to a file, offset and length.
3. If the frame is gigantic (ie. size > 1 Megabyte), the library gives an error.

Since jid3rL is an open source library, the threshold settings for these storage types could just be constants in a Java class. They won't need to change during program execution, but software developers using the library might want to tweak these thresholds themselves and recompile the JAR.

It would be nice if the first two frame storage types looked the same from the outside with a good abstraction. When I'm writing a tag to a file, I don't want to have to worry if a frame is coming an array of bytes or a file, I just want to take the list of frames and write them out one after the other.

Roy and I were also talking about frame ordering within the tag the other day and its implications. I'll have to blog about that next.