Rockbox mail archiveSubject: RE: APEv2 tag support?
RE: APEv2 tag support?
From: Fred Maxwell <rockbox_at_anti-spam.org>
Date: Thu, 8 Apr 2004 07:08:40 -0400
> In the tag specification link I had in the original post, you'll see
> that the people encouraging the use of APEv2 agree with you.
> "Size should be normally in the range of 1 KByte, NEVER more than 8 KByte.
> Larger external data should be stored externally using link entries.
> External data is much easier to process by normal programs, so there's no
> need to insert JPEG data to audio data. Especially storing album related
> information in audio tracks is stupid."
What they intend and what people will do are probably two very different
things. I don't think that Microsoft intended e-mail scripting and HTML to
be used to propagate viruses and worms, but that's what happened. I don't
think that the creators of Usenet intended people to post massively
multi-part messages to distribute porn, pirated software, and music, but
that's what is being done.
> I also agree with you on these last comment. ID3v1 tags are pretty good to
> me as well, except when I need more character length. The album covers,
> lyrics, multiple character sets, etc have already happened with ID3v2
> tagging though. If anything, APEv2 tags would be something to head towards
> the opposite of that.
That's why I strip out all ID3v2 tags. Also, no two programs seem to agree
on the use of them while ID3v1.1 tags are read fine by Rockbox, QCD, my
Riovolt, my Rio flash player, and my JVC in-dash car MP3 player.
Think of the pain it will cause if MP3s have even more types of tags. If
you use ID3v1 because you have hardware devices that support it, you'll have
to get software to copy info from other tag formats into that one. Forget,
and you start playing the song and find the info doesn't display. We need a
tag specification that specifically excludes the use of APE, ID3v2 and other
tags while requiring an ID3v1. That would guarantee backwards compatibility
(since everything reads ID3v1) while adding improvements for longer strings.
Received on 2004-04-08