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

[Ian Malone]

Ivo Emanuel Gonçalves wrote:
> 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.
> 

What I meant was really to tie into later on; you need new support for 
this in the one area it seems to be a target: portable players.

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

Semantics.  I don't think anyone is going to confuse a static cue-image 
with video.

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

Mine does read them, and it was probably an over-run bug in handling 
that was hit.  Amusingly you might speculate that this will hit players 
with better Vorbis support harder.

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

Yes, true.  But once your comment editor starts showing you comments 
with uuencoded binary data you're already in trouble.

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

You can't with vorbiscomment (you have to dump the comments, strip it 
and write them back, and vorbiscomment will not support safe 
round-tripping if I recall correctly, due to the new-line thing).  You 
can do it with the comment library.  So for a developer I think it's 
harder to add/subtract images that are already Ogg encapsulated as you 
just use liboggz or your own muxing (the already encapsulated is the 
tricky bit).

>> Helps keep a bit of OggMNG momentum up.
> 
> Er, I don't think albumart is the way to promote the use of OggMNG.
> 

I meant on the development side, but you touch on that later.

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

(over-zealous editing?)
<no current>
>> 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?
> 

No, I was writing a bit too quickly.  Current players may not crash, but 
they certainly wont know too convert the contents of an IMAGEDATA (or 
whatever) tag to a picture.  This is the kind of thing people add to put 
on their own players.

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

Yes, I was thinking about that.  The spec allows long comments, but 
people don't always write expecting everything that's allowed.

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

Yes, I don't see the choice as being much of an issue either way.  I 
can't help but feel the OggMNG thing is a neater solution if someone is 
going to do it, otherwise the cheap-and-cheerful approach isn't going to 
be too bad.  As to community effort, it's always down to what people 
want to (or can get support to do).

-- 
imalone