[Vorbis-dev] base64 ALBUMART vorbiscomment (was Re: [ogg-dev] Ogg/Spots and Ogg/MNG)

[Ivo Emanuel Gonçalves]

On 4/12/08, Ian Malone <ibmalone at gmail.com> wrote:
> any files with multiplexed pictures will now automatically be .oga, not .ogg.

Yes, that is true, but .oga's intended "audience" really isn't Vorbis,
but newer audio codecs in Ogg like CELT and OggPCM.  To everyone and
their mother .ogg is "that O.G.G. thing that's like MP3 but open
source", so while we do use .oga for Vorbis + multiplexed content it
isn't a good idea to diassociate it from .ogg because that's where
people expect to see Vorbis.

That, not to mention that by multiplexing visual content (an image),
it should in theory become .ogv.

Sorry, this is starting to get out of topic.

> It's easily understandable and has been proposed before.  Relatively
> simple to implement; application authors can do it themselves with
> access to a comment-reader and a png/jpeg library.

Yeah, that's really the main advantage.

> May well be problematic, I have seen one HW player which choked when
> comments were too long. (Though the manufacturer did fix the problem
> fairly quickly, which is why I keep pushing iAudio :) .)

This is a big concern, and I wish I had more audio devices to test
this out.  I only have a cheap brandless Chinese thing, but I did test
yesterday a file with an ALBUMART string and it didn't choke.
Hopefully, the majority are like it.  Most HW implementations probably
don't even interact with Vorbis Comments.  Mine, for instance, only
displays the file name.

> May make normal tag handling more difficult.  Harder to remove I'd say.

How?  All the Vorbis Comments Implementations I have dealt with edit
tag by tag.  If you want to remove a tag, you click delete tag, not
remove character by character from the whole string.  Any
implementation like that is already broken.

> Big headers are an issue when streaming.  Also uuencoding causes (a
> small amount of) inflation.

This may be a problem.  We'd need to carry on tests to make sure
Icecast wouldn't choke.

> Vorbis-only: support is easy to add for app authors, and vorbis-style
> comments are in many of the codecs, but you need to deal separately with
> each type then.  A small effort, but quite a lot of duplication resulting.

To be fair, only the Vorbis users requested albumart.  FLAC users
should in theory be able to use the tag too if they want, but this
wouldn't be something we'd see in other codecs like Speex and Theora.

> While application support may be harder, doing things like adding album
> art on the fly or stripping it out will be easier.

That really depends on the tools.  Using vorbiscomment one would
simply tell it to kill the ALBUMART tag.  On the other hand, you'll
need to use something like ogg-chop to get rid of a multiplexed image,
as far as my understanding of handling multiplexed streams goes.

> Helps keep a bit of OggMNG momentum up.

Er, I don't think albumart is the way to promote the use of OggMNG.

> Will need to provide a library if anyone is going to use it.  Need to do
>   the full .oga stuff: Skeleton header, maybe CMML or M3F manifest
> (though for this simple application a manifest is probably not
> necessary, and omitting it is still less ad-hoc than the
> uuencode/comment thing).

The new file extensions only recommend the use of Skeleton.  CMML and
M3F would only need to be added if there was a need for
subtitles/lyrics or metadata, respectively.

> HW player will support comment-based images anyway

I thought you said it was only your player, which had been since
fixed.  Have you found others that crashed/froze, too?

> super-long comments

You know, a JPEG is usually ~30 KB.  The Vorbis Comment spec states
the information can be much bigger than that.

> muxing might encourage people to start thinking about .oga may be a good
> thing.  Lack of current support either way means there is a free choice,
> very much down to whether you can get someone interested in writing the
> OggMNG static subset stuff

I understand where you are going, and I agree with it, but I reckon
that would be too much work for something intended only to please a
small audience.  Of course the embed approach would lead to the
creation of a liboggmng, which would then have other uses, but unless
there's really a need for such library (I don't know), the community's
efforts should be likely spent elsewhere.

-Ivo