Audacity Forum

ID3 meta-data (version 2 and higher) in MP3 files is usually forllowed by a number of spare bytes (typically hundreds to thousands) that allow the ID3 meta-data to be edited without a complete re-write of the MP3 file (which is time-comsuming for larger MP3 files). Audacity writes MP3 files with exactly the number of bytes needed to store the specified meta-data, without leaving any spare bytes.

It would be nice to have a function to specify the amount of spare bytes desired (or to conserve the number of spare bytes that were found in the input file).

Of course, adding spare bytes is a tradeoff between maximising performance versus minimising disk use, but a thousand bytes on a MP3 file of typically dozens of gigabytes is all but negligeable.

Please apologise if Audacity already contains this function.

Reinier Bakels

rbakels wrote:ID3 meta-data (version 2 and higher) in MP3 files is usually forllowed by a number of spare bytes (typically hundreds to thousands) that allow the ID3 meta-data to be edited without a complete re-write of the MP3 file (which is time-comsuming for larger MP3 files).

What software are you using to edit the metadata? I use EasyTag and it can write additional metada almost instantly even with very large files.

Thansk for the quick reply. Am I correct to note that you implicitly confirm that the function I described is not currently in Audacity?

Tha answer to your question is that I wrote my own software for that purpose, written in C++. I am surprised that you are able to edit ID3 data and expand ID3 space "almost instantaneously", since that requires (almost) the entire file to be written, often dozens of megabytes, and that process is totally dependent on the speed of the underlying hard- and software (Windows in my case, and the disk drive of course).

Anyway, it is a design feature of ID3 (V2 and above) to allow spare meta-data space in a file, in order to minimise disk access. Typically the MP3 files I obtained from various sources do use the feature.

rbakels wrote:Am I correct to note that you implicitly confirm that the function I described is not currently in Audacity?

There appears to be a little padding (zeros) but not much.

rbakels wrote:I am surprised that you are able to edit ID3 data and expand ID3 space "almost instantaneously", since that requires (almost) the entire file to be written, often dozens of megabytes, and that process is totally dependent on the speed of the underlying hard- and software (Windows in my case, and the disk drive of course).

I've just tested with a 58 MB MP3 and checked to see where the data was added using a Hex editor. The additional metadata was added almost instantly and was inserted near the beginning of the file, so there was more metadata after updating the file than before and the file size had increased by about 1 kB. My computer is a cheap old Acer Aspire laptop.

Let me say first that I do not complain. Firstly, I wondered whether the function exists, and apparently the answer is no. Secondly, I made a suggestion for improvement.

In my perception, the debate how much time it takes to rewrite a MP3 file misses the point. I repeat: having spare bytes in the ID3 header is a design feature of ID3V2 and higher, and the argument whether it is unneeded is academic.

Incidentally, I did a test with a 206 MB Mp3 file. The expansion took 9.8 seconds on my laptop. This is a substantial amount of time since often multiple files have to be changed.

So we are clear what we are talking about, is it this from http://id3.org/d3v2.3.0 ?

It is permitted to include padding after all the final frame (at the
end of the ID3 tag), making the size of all the frames together
smaller than the size given in the head of the tag. A possible
purpose of this padding is to allow for adding a few additional
frames or enlarge existing frames within the tag without having to
rewrite the entire file. The value of the padding bytes must be $00.

ID3v2.4 (which Audacity doesn't use) also adds ( http://id3.org/id3v2.4.0-structure ):

A tag MUST NOT have any padding between the frames or between the tag
header and the frames. Furthermore it MUST NOT have any padding when
a tag footer is added to the tag.

Certainly the two tagging apps I use (dBPowerAmp and Mp3tag) add many bytes of padding after the final frame and Audacity adds none as far as I can see.

Have you ever seen a tag writing app that allows to turn padding on or off or specifies the number of bytes of padding allowed? It seems to me we should pad or not.


Gale

I used the RealAudio player to convert my CDs into MP3 files. AFAIK, It adds automatically some spare space. I don't know the exact number but I guess a couple of thousands bytes.
All the MP3 files I got through various sources either contain no ID3 information at all (and no ID3 header), or some spare space. Audacity factually is an exception.

Are we talking about exactly what I indicated or not, please?

If you are not sure, please upload an example MP3 that has the padding you think is good.

Gale

As an example: I just ripped a CD using the RealAudio player. For all files, it reserves 4086 bytes for ID3 meta-data, and it uses a little more than 64% of that space to store its ID3 frames, leaving about 1450 bytes for future use. I have not seen an option to specify the amout of spare space.
I often edit ID3 meta-data for uniform display on my telephone.

rbakels wrote:I repeat: having spare bytes in the ID3 header is a design feature of ID3V2 and higher,

If I'm understanding your suggestion correctly, the feature that you are requesting is "optional"

From http://id3.org/d3v2.3.0

It is permitted to include padding after all the final frame (at the
end of the ID3 tag), making the size of all the frames together
smaller than the size given in the head of the tag. A possible
purpose of this padding is to allow for adding a few additional
frames or enlarge existing frames within the tag without having to
rewrite the entire file. The value of the padding bytes must be $00.

Have I got the right feature?
If so, then I agree that your request is perfectly valid and not unreasonable (but obviously we need to understand exactly what feature you are asking for in order to record your request.) Of course this would leave the question of how much padding to add. If someone wants to insert album art, that could be quite a lot of data.

There is already a feature request to not include any metadata in exported files, so perhaps a bit of clever GUI design could include both options.

Regarding the speed of updating metadata, could your application read the header and metadata, trim that from the start of the file, then create a new file containing the header and updated metadata, then concatenate the two files without needing to rewrite the audio data?