[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:
>> Helix from nightlies should be a lot more robust than the old RealPlayer
>> 10-era Helix.  Aaron Colwell did some fixing a while back, but the Helix
>> release wasn't updated for a long time (though I saw someone mention a
>> v11 recently).
> 
> That's actually good to know.  I hope they will get the new version
> out soon.  I remember seeing a message on their mailing list about
> some improvements to Theora decoding.
> 
> Ian, by the way, what is your take on the albumart issue?  Would you
> like to comment the current proposal?  Perhaps propose something
> better?  I know you have looked into the issue before today, so your
> opinion is valuable.
> 

It's a bit late here, so I'm not attempting to compose this into a 
coherent essay.  You'll have to put up with random thoughts.

Positives:
It won't break current players.  Software players aren't a major 
concern, as they are slowly being updated, but hardware players tend to 
expect Vorbis I.  N.B. though: any files with multiplexed pictures will 
now automatically be .oga, not .ogg.  That's a clue to the user and the 
hypothetical Vorbis stripper tool would produce something you could play.

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.

Negatives:
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 :) .)

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

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

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.


On the other hand, muxed images:
Positives:
Doing this gives support across all Ogg encapsulated codecs.

Labels files .oga, helps to push the new Mime types and provides a 
reason to support muxed Ogg files.

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

Helps keep a bit of OggMNG momentum up.

Negatives:
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).

Will prevent playing on some HW players (certainly the ones I have 
access to).  Though see the .oga / .ogg discussion above and no current 
HW player will support comment-based images anyway; anyone wanting to 
use this will need a new player that can support it.


So I think the 'breaks current players' is a bit of a red-herring, as it 
wont work on anything current anyway (and really this appears to be the 
only application for it, as SW players tend to pull images from the 
web).  The .oga extension is likely to prevent players that can't read 
it from trying; whereas super-long comments in .ogg may crash them. 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 (starting a new job on Monday, so unsure how 
much time I'll have).

I assume it was Monty who wrote the original: "much like someone jotting 
a quick note on the bottom of a CDR."  What was the reasoning then and 
is it still valid?

-- 
imalone