Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: APEv2 tag support?

Re: APEv2 tag support?

From: Noah Smith <midblue_at_carolina.rr.com>
Date: Sun, 11 Apr 2004 01:54:04 -0400

"Fred Maxwell" <rockbox_at_anti-spam.org> wroted:
Hi Fred,
> > 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 don't know if anyone can quite reason what Microsoft is thinking about
half the things they do =P, but as for your second example:

At the same time I doubt the Usenet designers are losing sleep over what the
network is being used for. It's done its job of communication well for a
long time. You aren't forced to use it for those aims. In that same respect,
you aren't forced to stick images and other extraneous data into a tag, APE
or otherwise. A potential for misuse shouldn't mean that an idea is written
off; it's your audio collection and your prerogative on how you handle the
tags.

As for other predictions about people inserting executables, pictures, etc
into the tags, this has not happened thus far, and the tag system has been
around for a while now. Everyone using it seems to agree that data doesn't
belong in the tag where it can/will muck up the mp3.

> > 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.

I'm perfectly willing to take care of syncronizing tags for music in my
collection. It'd be the same idea as someone managing ID3v1 and 2 tags at
the same time. The difference in this would be that the APE tags would
"degrade" better than ID3v2 tags when played on unsupported players. As for
your new format idea, it would still be another tag format to worry about,
and such a tag doesn't even exist now. I'm not trying to convince you that
APEv2 is perfect, but I would at least say that it's a better idea than
ID3v2 was.
-- 
Noah
.Charter Member of The League For Claiming Membership
.In Your Sigs For Groups That Are Really Just For
.Claiming Membership In Your Sig
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2004-04-11

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy