Page 2 of 2

Re: Conserving/creating ID3 spare space

Posted: Mon Jun 16, 2014 9:28 am
by rbakels
Yes indeeded that is how it works. Applications that read ID3 meta-data must stop when either the end of the meta-data area is reached (if it is fully used), or when a binary zero frame ID is found (if it is not fully used). The end of the meta-data area (not the actual end of the meta-data if spare byte are included!) is defined bu the length field in the ID3 header at the front of the file.

Yes, meta-data may become large if you include pictures (APIC frames), so occasionally the remains a need to expand the meta-data area. I guess a good compromise is to add 2K of spare space. That allows most text editing needs.

ID3V2 and higer (V4 is the latest) meta-data is placed at the front of the file, in contrast to the very old fixed-format ID3V1 meta-data which is placed at the end of the file. ID3V2++ are supposed to offer more flexibility - and spare space is relevant for that flxibility.

As far as I know, the Windows disk I/O API does not allow files to be extended at the front, starting them earlier and leaving the end at the same location, so that the meta-data area can be extended without moving the body of the file (the actual MP3 frames). Pointers can not achieve the same thing, since an MP3 file has a fixed structure of an (optinal) ID3V2++ meta-data followed by the MP3 data (optionally followed by other (obsolescent) meta-data, like the ID3V1 data mentioned above, sometimes still present in modern files, and "APE" tags - but do not bother about those types of meta-data).

Re: Conserving/creating ID3 spare space

Posted: Tue Sep 23, 2014 4:30 pm
by waxcylinder
Can someone summarize succinctly what the FR here actually is ?

Re: Conserving/creating ID3 spare space

Posted: Tue Sep 23, 2014 9:13 pm
by rbakels
FR = "function request"?

If Audacity writes a MP3 file with ID3 meta-data, it should leave some spare space, ideally variable, or otherwise for instance 2000 bytes. Presently, Audacity allocates precisely the amount of space needed, leaving no spare space.

Typically applications writing MP3 files leave spare space. Distributed files typically contain spare space. The rationale is that thus ID3 meta-data can be easily extended, whereas otherwise the entire file must be re-written. MP3 files can become very large, 100 MB+.

Re: Conserving/creating ID3 spare space

Posted: Tue Sep 23, 2014 9:25 pm
by Gale Andrews
waxcylinder wrote:Can someone summarize succinctly what the FR here actually is ?
I understand what the request is, so if you are still unclear, please just transfer the URL to "Pending Feature Requests".


Gale