[Vorbis-dev] Cover art

[Ian Malone]

2009/4/2 Goran Markovic <skromnibog at gmail.com>:
>> Yes, please ignore that last bit; it is really about next generation
>> stuff for general Ogg cover-art, but the Vorbis-I format (i.e. Ogg
>> Vorbis files) is quite rigidly fixed, so the comment tag approach
>> you're pursuing is the one that's needed.  What you've already
>> implemented is not wasted as the only thing I can really see changing
>> is exactly how the FLAC picture block is placed in the tag contents.
>
> The problem is writing of cover art to ogg files. To support writing
> of cover art, cover art format should be standardized as soon as possible.
> Nero doesn't want to create files with cover art that in future will not be
> supported by other software or hardware.
>

Ogg is the encapsulation format (like avi), whereas '.ogg' files are
Vorbis-I and will not change:
<http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions>.  The
proposal under discussion is the only way art can be done for
Vorbis-I.

>
>> How should multiple images be embedded? Several METADATA_BLOCK_PICTURE
>> structs concatenated in one comment field, or several comment fields
>> with the same name, each containing one METADATA_BLOCK_PICTURE struct?

> I would prefer several comment fields, each containing one picture.
> It is much easier for handling.
> Order for same cover art type is of course important.
>

Yes, this seems to be the sensible approach.

>> I've just updated it on my server. You can now get the new re-paged ogg file
>> (from Ian Malone, thanks) from http://www.audioranger.com/with_coverart.ogg
>> The old one is also still available at
>> http://www.audioranger.com/with_coverart_old.ogg
>
> Great! Thanks!
> As expected extracting the cover art from the new file works without
> any changes in the source code :)
>

It should be noted that that file was created before the base64
suggestion.  Base64 should address some of the problems previously
noted (control characters in the stream, slightly more efficient), so
there's one more iteration to go.  I should be able to post a final
example this evening.

>> If you're going to use the flac metadata format, I'd suggest being
>> explicit about that in the tag name, with FLAC_PICTURE or
>> FLAC_METADATA_BLOCK, etc. instead of a generic COVERART tag. Do you
>> propose to include the block header with the internal length, or just
>> the picture block?
>
> Hmmm. Another new proposal. Who is responsible here for setting standard?
> Who can guarantee that it will not change (unless of course at some point
> some big problems arise)?
>

> 'METADATA_BLOCK_PICTURE'? Why? Why not stick to 'BINARY_COVERART'
> I guess software and hardware players should be checked
> again with this new encoding.

The name is window dressing/bicycle shed: there's no reason to change
it once it's actually in use.  Additionally what gets written up in
specifications is only half the story, the other half is the existing
conforming implementations.  If it gets implemented then there is a
strong reason not to change: we want a standard to allow
interoperability, not to make people chase their tails.

The reason there seems to be (a decreasing amount of, I hope) flux
here is that this hasn't been implemented previously, changing it at
this stage isn't going to break existing hardware/software any more
than incompatibilities with the older approach would.  We could stick
to BINARY_COVERART, but I think changing it at this point is a good
idea since:
1. It marks a clear change from the suggestion on the wiki to a more
thoroughly thought out standard.
2. The contents are neither binary (they were according to the outline
on the wiki) nor necessarily cover art.
3. The more specific name (METADATA_BLOCK_PICTURE) says exactly what
it is and means searching for documentation is easier.

Thanks for your help on this, I think we're making progress.

-- 
imalone