Hi, there was a thread a few months ago about album art, and how to embed it in an Ogg stream. The outcome was unconclusive, and kind of settled on the existing practice of adding a uuencoded image in a Vorbis comment, or similar. A better solution would be to embed those images as a separate stream, including hints as to what image represents (front cover, back cover, etc). The obvious candidate for this would be OggMNG, but it seems to be dead too. Kate streams can include PNG images, so are another possibility, but the problem of telling a client what each image is remains. One solution would be to add each image as a separate Kate stream with a specific category (eg, "art/front-cover", "art/back-cover", etc). This would mean adding as many categories as possible image types. Another would be to add a single Kate stream, with a category of, say, "album-art", and different data packets, presumably with a zero presentation time, each holding an image. The description could then be using the packet's text with a free description. This would make the description be in a particular language too. This post is a starting point for gathering info about what needs to be expressed, what information needs to be stored, and what links need to be made between those. Then, I'll be able to see whether a Kate stream could carry album art, and how. Thanks
On Mon, Oct 13, 2008 at 6:02 AM, ogg.k.ogg.k at googlemail.com> there was a thread a few months ago about album art, and how to > embed it in an Ogg stream. The outcome was unconclusive, and kind > of settled on the existing practice of adding a uuencoded image > in a Vorbis comment, or similar.FLAC has explicit support for album art. Is there some way to implement it in Ogg in a consistent way? Let me find you a link... here you go: http://flac.sourceforge.net/format.html#metadata_block_picture Note that it supports many kinds of graphics other than just album art. Mike -- Michael David Crawford mdcrawford at gmail dot com Enjoy my art, photography, music and writing at http://www.geometricvisions.com/ --- Free Compact Disc ---
On 10/13/08, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote:> The outcome was unconclusive, and kind > of settled on the existing practice of adding a uuencoded image > in a Vorbis comment, or similar.COVERART's the name. There's at least one known software to be using it.> Kate streams can include PNG images, so are another possibility, > but the problem of telling a client what each image is remains.A good proposal, except for the fact most album art is JPEG. Not forgetting either that, semantically, it's pretty bizarre to have album art in a text format. Not that it's better to embed JPEG's in a text tag in Vorbis, but since it's already being employed in the wild I for one would rather embrace what works for that niche market than creating a whole new solution that may just not be what they want. -Ivo
> FLAC has explicit support for album art. Is there some way to > implement it in Ogg in a consistent way?As is, those FLAC pictures can't be used in a non FLAC stream (eg, Vorbis). One could create a new stream type that's headers only (like Skeleton) and containing only FLAC picture records, however.
On Mon, Oct 13, 2008 at 6:40 AM, Ivo Emanuel Gon?alves <justivo at gmail.com> wrote:> A good proposal, except for the fact most album art is JPEG. Not > forgetting either that, semantically, it's pretty bizarre to have > album art in a text format.I *desperately* want to provide the cover art for my own album in PDF format. Presently I provide JPG in the MP3s; at 72 DPI it looks really terrible. Both my CD label and case insert use small text and fine, precise vector graphics. I *could* provide PNG or LZW-compressed TIFF, which allow one to specify the resolution, but both would greatly increase the file size in a way that wouldn't be at all necessary if I could provide PDF. SVG would be acceptable too, but only if I could compress it. If we could agree on some standard for providing vector graphic art, I would be more than happy to implement it from the very first release of Ogg Frog. (I do not yet provide art in my Ogg Vorbis and FLAC tracks.) Download my album to see for yourself ----------------------------V Mike -- Michael David Crawford mdcrawford at gmail dot com Enjoy my art, photography, music and writing at http://www.geometricvisions.com/ --- Free Compact Disc ---
> A good proposal, except for the fact most album art is JPEG. Not > forgetting either that, semantically, it's pretty bizarre to have > album art in a text format.Well, since it also carries DVD subtitles, which are paletted images, that's not a big jump to album art. The JPEG point is taken though.
I think we have to discuss a fundamental question about coverart first: is coverart a header-type content or a time-aligned type content? It was my impression that it is mostly header-type content, i.e. concerns the full file rather than segments of it. Therefore, embedding it into any of the time-aligned streams (Kate, CMML, OggMNG) doesn't make much sense to me. It should be in a header. As headers go, we have vorbiscomment and we have skeleton. If the coverart goes anywhere, that's where it should go IMHO. Vorbiscomment is generally used for metadata type header information. Skeleton doesn't really have a space for including this kind of information and would need to be extended. Since we already seem to have a working solution inside vorbiscomment, why not just use that? Regards, Silvia. On Tue, Oct 14, 2008 at 12:02 AM, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote:> Hi, > > there was a thread a few months ago about album art, and how to > embed it in an Ogg stream. The outcome was unconclusive, and kind > of settled on the existing practice of adding a uuencoded image > in a Vorbis comment, or similar. > > A better solution would be to embed those images as a separate > stream, including hints as to what image represents (front cover, > back cover, etc). The obvious candidate for this would be OggMNG, > but it seems to be dead too. > > Kate streams can include PNG images, so are another possibility, > but the problem of telling a client what each image is remains. > > One solution would be to add each image as a separate Kate stream > with a specific category (eg, "art/front-cover", "art/back-cover", > etc). This would mean adding as many categories as possible > image types. > > Another would be to add a single Kate stream, with a category of, > say, "album-art", and different data packets, presumably with a > zero presentation time, each holding an image. The description > could then be using the packet's text with a free description. > This would make the description be in a particular language too. > > This post is a starting point for gathering info about what needs > to be expressed, what information needs to be stored, and what > links need to be made between those. Then, I'll be able to see > whether a Kate stream could carry album art, and how. > > Thanks > _______________________________________________ > ogg-dev mailing list > ogg-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev >
Hmm. Another alternative would be to invent another header packet that just contains albumart, like flac's metadata_block_picture. I think it would be better if we improved the vorbiscomment specification (http://xiph.org/vorbis/doc/v-comment.html) and included more of what flac's metadata_block_picture allows. There is already a wiki page for vorbiscomment improvements: http://wiki.xiph.org/index.php/Vorbiscomment . Cheers, Silvia. On Tue, Oct 14, 2008 at 12:21 AM, Michael Crawford <mdcrawford at gmail.com> wrote:> On Mon, Oct 13, 2008 at 6:02 AM, ogg.k.ogg.k at googlemail.com >> there was a thread a few months ago about album art, and how to >> embed it in an Ogg stream. The outcome was unconclusive, and kind >> of settled on the existing practice of adding a uuencoded image >> in a Vorbis comment, or similar. > > FLAC has explicit support for album art. Is there some way to > implement it in Ogg in a consistent way? Let me find you a link... > here you go: > > http://flac.sourceforge.net/format.html#metadata_block_picture > > Note that it supports many kinds of graphics other than just album art. > > Mike > -- > Michael David Crawford > mdcrawford at gmail dot com > > Enjoy my art, photography, music and writing at > http://www.geometricvisions.com/ > --- Free Compact Disc --- > _______________________________________________ > ogg-dev mailing list > ogg-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev >
On 13-Oct-08, at 2:10 PM, Silvia Pfeiffer wrote:> is coverart a header-type content or a time-aligned type content?Well, it's collection-level metadata, so it doesn't belong in files at all. :)> It was my impression that it is mostly header-type content, i.e. > concerns the full file rather than segments of it.It makes sense to reference it per-chain-segment in an Ogg context.> Therefore, embedding it into any of the time-aligned streams (Kate, > CMML, OggMNG) doesn't make much sense to me. > It should be in a header.When I've suggested OggMNG (or rather OggJNG and OggPNG) for cover art in the past it was in that sense that it be a 'header only' stream, the way skeleton is. I'd suggest defining an album-art reference in the skeleton fishhead that points to such a stream. We have the OggMNG spec for embedding png and jpeg images already, and svg could use a similar embedding to what we already do with cmml. But if it is in fact header only, it might be reasonable to put just anything in there, including JFIF and PDF. As usual it comes down to what people are willing to support. We need the vorbiscomment option because the spec allows audio players to reject non-degenerate streams. So for audio .ogg files this is the only option. I don't think this is a good mechanism for .oga or .ogv files. Note that either way this makes for an even bigger bitrate spike when streaming, so we probably want the ability to use an external reference for that. And make icecast covert on the fly... -r
On Wed, Oct 15, 2008 at 4:52 AM, Christopher Montgomery <xiphmont at gmail.com> wrote:> On Mon, Oct 13, 2008 at 8:02 PM, Ralph Giles <giles at xiph.org> wrote: > >> We need the vorbiscomment option because the spec allows audio >> players to reject non-degenerate streams. So for audio .ogg files >> this is the only option. I don't think this is a good mechanism >> for .oga or .ogv files. > > The majority of harware players will reject any stream with headers > that are 'too big' to fit in their limited buffering space. Album art > in the comments would probably cause most portable players to reject > the stream as well.What speaks against just putting hyperlinks into the header? Or a compromise solution of only allowing limited size images into the header with full-scale images required to be hyperlinked? Cheers, Silvia.
On Tue, Oct 14, 2008 at 10:52 AM, Christopher Montgomery <xiphmont at gmail.com> wrote:> The majority of harware players will reject any stream with headers > that are 'too big' to fit in their limited buffering space. Album art > in the comments would probably cause most portable players to reject > the stream as well.Aha, so another vote for 'it doesn't belong in the stream at all'. So lets leave the vorbiscomment part as it stands and concentrate on embedding/linking for multiplexed streams. -r