Re: Conserving/creating ID3 spare space
Posted: Mon Jun 16, 2014 9:28 am
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).
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).