similar to: Album art - requirements

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

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

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

>> So, a possible way to encode album art would be: >> >> - a Skeleton stream with appropriate header messages >> - one Kate stream per image, carrying a PNG image >> (alternatively, use Ogg/MNG, if someone brings it from the dead) >> [...] Silvia wrote: >Interesting proposal. Not sure it won't over-complicate album art though... Well yes, of course

I've added ogg support to my player app. Now I'd like to be able to write/read album cover art (jpg, png, what ever) out of the ogg file and display it, as I do with mp3s. This assumes that an album cover art picture can reside inside of an ogg file. I've read through the vorbis.com/faq.psp as well as the list archives and haven't found any direct answers. The section on comments

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.

>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

Is there any size limitation for album art? I have a user who says adding large artwork (from a scanner) is corrupting the file metadata. I don't know if this is a flac limitation, a tag lib issue, or something I'm doing. Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL:

Does anyone know if there are any players that use the id3v2 album art people mention every so often? -- imalone

Pierre-Yves Thoulon wrote: > None, apart from the standard metadata block size limitation (2^24 > bytes, e.g. 4GB). Pretty big for any kind of album art... 2^24 = 16777216, i.e. only 16 Megabytes. > Kind regards. > > Pyt. > > >> Le 10 mai 2017 à 17:11, Scott Brown - scottcbrown at gmail.com >> <flac-dev.pyt.8c0cc6600b.scottcbrown#gmail.com at

"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

> 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

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

Hello all, I recently upgraded the libFLAC used in my application Max (http:// sbooth.org/Max/) to 1.1.3 and added preliminary support for album art. During the upgrade I evidently made some coding mistakes with interesting results. I've combed everything over and can't quite see the problems. I've become somewhat frustrated because my code didn't really change

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

Daniel, before you step over everything that has been done before, we need to determine what exactly is the use case for your new specification. What concerns metadata, we currently have: * vorbiscomment - this is a header at the beginning of a logical bitstream which has metadata that refers to the complete file; there is a specification, which has been public for a long time and is the

> This'd be codec specific Unless a Skeleton track is used instead (this is supposed to describe the tracks within a multiplexed Ogg stream). But Skeleton is nascent too.