Stripping ID3 Tags in ITunes

In article ,
Lewis wrote:

> In article ,
> Gregory Weston wrote:
>
> > In article ,
> > Lewis wrote:
> >
> > > In article ,
> > > Gregory Weston wrote:
> > > > If you simply blank out the
> > > > fields, the empty structure is still there taking up some random amount
> > > > of space on your disk and consuming extra bandwidth any time the file
> > > > is
> > > > transfered among machines or even from disk into memory.
> > >
> > > And how large is an ID3 tag? 100 bytes? 1000 bytes?
> >
> > From a practical standpoint, the size is limited to 256 MB. In real
> > life, I think you'd have a hard time finding one that's larger than a
> > couple of hundred KB, and more often probably about 50 KB.
>
> Wow. That seems like a lot.

A lot of people store cover art in the ID3 tag. One decent-sized JPG and
your done.

> That wasn't why I asked, exactly. I really wanted to know. I looked at
> the strings output from one mp3 and it seems like it was only a few
> bytes, song artist and album name and that was all.

It varies from file to file and editor to editor, but if you really want
to see how much space an ID3v2 structure is consuming, do a 'hexdump -n
10 -C myfile.mp3' in a terminal and look at the 7th-10th bytes. Multiply
them by 2097152, 16384, 128 and one respectively and add those products
up. Then add 10. If the 6th byte divided by 32 has a fractional value of
at least 0.5, add another 10.

Gregory Weston a écrit :
> In article ,
> Anic297 wrote:
>
>> Gregory Weston a écrit:
>>>> And how large is an ID3 tag? 100 bytes? 1000 bytes?
>>> From a practical standpoint, the size is limited to 256 MB. In real
>>> life, I think you'd have a hard time finding one that's larger than a
>>> couple of hundred KB, and more often probably about 50 KB. How much is
>>> there after you've studiously blanked everything out depends on what you
>>> had in there to start with and how aggressive the editor is about
>>> reclaiming space when it's no longer used. It would be atypical, I
>>> think, to see one as small as a thousand bytes no matter how little was
>>> stored in there. So, yes, you *are* freeing up usable disk space, rather
>>> than just getting a little more slack within an allocated block.
>> Really that big? I thought a tag would simply take it's size in byte
>> (programmatically, the length of the string of characters, or the bytes
>> of a long integer (or similar)). Are they coded specifically?
>
> There are two things coming into play that I think your expectation is
> missing. One is that an ID3 tag can hold arbitrary data and some types
> of reasonable data get fairly large. I get one or two e-mails a month
> from DockArt users who hope I can support multiple images, for example,
> instead of just the primary cover art. (And the main reason I don't so
> far is that M4A and M4P files use opaque metadata.)
>
> The second factor is that because we're looking at a user-editable
> structure tacked onto the front of a file that's typically much larger
> than the structure itself, resizing that structure is a relatively
> expensive operation. You don't really want to rewrite a 10MB file just
> because your metadata has shrunk by 30 bytes. So the common (and
> recommended) behavior among editors is to only resize the structure when
> necessary or when there's a *lot* of slack space within the structure
> that the user might want for something else. The fuzzy definition of "a
> lot" is where you run into the chance that dozens or hundreds of KB
> might be consumed but unused.

Thank you, very good explanation.