similar to: Album art - requirements

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

> 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. :) Well right, but the problem is that external coverart files are unhandy (broken links!!, streaming...) Users therefore want to embed them most times, as you can tell from other audio file formats: the majority of cover art is

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

Somebody (sorry, can't find original post) wrote: >> I don't mind (and approve of) the idea of reusing as much of proven >> standards as we can. But putting it in a Vorbis comment will in fact >> piss off people who then can't play the file. It's not as much a >> qestion of displaying the tag as text (although that is a concern) >> it's that most

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.

Hello to the people reading this list! I am developing tagging support for ogg vorbis in Nero products and we are currently thinking of supporting cover art in ogg files. What is the current state of proposal for cover art in ogg files? Is this http://wiki.xiph.org/index.php/VorbisComment#Cover_art still the latest information? Regards, Goran -------------- next part -------------- An HTML

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

"Santiago Jimeno" wrote: > Flac files, as us knows, follows the Vorbis Tags system included in block 4 > Recently Vorbis has established the possibility to include picture files by > means of 2 Tags: COVERARTMIME AND COVERART. > To work therewith is quite easy. No. this in incorrect. The VorbisComment "COVERART" was only ever unofficial, and has been deprecated

>I have more than once said I'm in favor of the vorbiscomment solution. >It's ugly, it will break this and that one other player, but these >people want the feature that bad so they won't mind about any of those >issues. Plus it means little or no work for a feature the people who >actually do code care little about, and it certainly helps that >there's already

I have more than once said I'm in favor of the vorbiscomment solution. It's ugly, it will break this and that one other player, but these people want the feature that bad so they won't mind about any of those issues. Plus it means little or no work for a feature the people who actually do code care little about, and it certainly helps that there's already at least one

>I don't mind (and approve of) the idea of reusing as much of proven >standards as we can. But putting it in a Vorbis comment will in fact >piss off people who then can't play the file. It's not as much a >qestion of displaying the tag as text (although that is a concern) >it's that most hardware players that only have 10-20kB available for >stream buffering

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

You said "With the exception of where to put a picture file, VorbisComments in a Vorbis stream are the same as VorbisComments in a FLAC stream." In METADATA_BLOCK_PICTURE case they would not be the same. Up to now we could exchange the complete block of VorbisComments. But with the addiction of METADATA_BLOCK_PICTURE doesn't happen this way. In Ogg files the METADATA_BLOCK_PICTURE

WebP (imagepart of VP9) is better then JPG AVIF (imagepart of VPX/AV1) is better then HEIF please support in OPUS file for album arts more then JPG and PNG... WebP and AVIF are free imageformats can store multiple images thats good for the problem with METADATA_BLOCK_PICTURE only can store one file. i try to push some devs of player and converter to support this too. wbr from berlin

As I understand it, any attribute=value line in a vorbis comment can be arbitrarily long (up to 2^32 -1 bytes). The easytag program allows adding the album cover art and other images into the vorbis comment as ALBUMART=xxxx where xxxx is a base64 encoded data of the image file. This makes for a very long line. If I do this to extract the vorbis comment of a file with an embedded cover art (the

Hi, [ Was away the last few days, so this partly overlaps on things that that have been mentioned in this thread. Since the consensus seems that Vorbis comment encoding is the way to go, it's a bit moot, but here it is anyway ] Following up on the possibility to tag various images as different types of album art, I thought of adding that tagging information in a Skeleton stream. Since

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

OK Martin. Thank you for the explanations and for your time. I am writing a program that reads and writes all existent Tags types. It lacks only to end the edition (rewriting) of "Native" Flac and Matroska. Both cases for the same problem: the separation of Tags and Picture in different blocks. In Flac I resolved it, but now I have to add METADATA_BLOCK_PICTURE. Reading Vorbis

Hello, I'd like to ask about the possibility of embedding pictures like an album cover artwork into a vorbis comment header. Since the data in a comment string after the separating "=" has a defined length, this could theoretically also be binary picture data. For example "PICTURE=[...any binary data...]" It only would be a problem for existing software which isn't

Oops, meant to add, there's absolutely no restrictions on the format of any picture block, either, and opusenc will already just add whatever gets passed in without even trying to verify anything about the file format. That's up to tagging and playback software to support; foobar2000, for instance, only supports formats that are part of Windows' GDIplus library. On Fri, Jun 21, 2019