similar to: Flac] Where Cover Art?

Displaying 20 results from an estimated 1100 matches similar to: "Flac] Where Cover Art?"

2011 Jan 22
0
Flac] Where Cover Art?
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
2011 Jan 20
1
Flac] Where Cover Art?
"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
2009 Jan 27
1
frames number & compression level
If compression level is not default (!=5), is it stored? If compression level is stored in some case, where I can find it? Frames number works OK according to your instructions. Thank you ----- Original Message ----- From: "Josh Coalson" <xflac at yahoo.com> To: "Santiago Jimeno" <sjimeno at ya.com>; <flac at xiph.org> Sent: Tuesday, January 27, 2009 7:43
2009 Apr 23
0
vorbis-tools patches (was: Cover art)
2009/4/2 Ian Malone <ibmalone at gmail.com>: > If no-one is keen then I'll take the vorbiscomment and ogginfo > patches. ?They are lower priority than actually updating the wiki, but > I might be able to do that this evening. > Adding a -s option to ogginfo and vorbiscomment to hide METADATA_BLOCK_PICTURE contents git://github.com/imalone/imalone_vorbis-tools.git
2009 Jul 23
0
Fixing ogg vorbis corruption caused by bad metadata
On Wed, Jul 22, 2009 at 7:24 PM, Martin Leese<martin.leese at stanfordalumni.org> wrote: > Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > >> Martin Leese wrote: >>> Anyway, calling alloc()s with no corresponding >>> free()s is a memory leak. Not good code. >> >> The alloca() function allocates space on the stack and >> that
2009 Jan 27
0
frames number & compression level
Hi Harry I attach you FLACInfo C# class and also for the forum. I already added frames number code. Code for VORBIS Tags is not included . But taking as sample the code for Vendor and following the specifications you can make it easily.With a loop similar to Vendor you can read all Tags. It's only necessary to keep in mind two things: VORBIS is litteleendian and FLAC doesn't use the
2009 Jan 25
2
frames number & compression level
I am making a program to obtain information from FLAC files in Visual Basic. NET language. If somebody needs it I can send it. I can also translate it to C #. But I have read the documentation and I have looked for in sdk 1.2.2 and I don't find how to get the frames number of the file and the used compression level (5 default and others) Can somebody help me? Greetings. Santiago Jimeno
2008 Oct 15
0
Album art - requirements
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
2009 Mar 26
8
Cover art
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
2009 Jul 23
1
Fixing ogg vorbis corruption caused by bad metadata
> However, there is a general point. ?Xiph policy > now encourages cover art in VorbisComments > using the METADATA_BLOCK_PICTURE tag, > visit: > http://wiki.xiph.org/VorbisComment#Cover_art > > This means that VorbisComments can be > huge, and so memory for them now needs to > be allocated from the heap, not the stack. Huge is relative. Are people really sticking
2008 Oct 18
1
Album art - requirements
>> 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
2008 Oct 15
0
Album art - requirements
> 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
2008 Apr 12
1
base64 ALBUMART vorbiscomment
" Ivo Emanuel Gon?alves " <justivo at gmail.com> wrote: ... > To be fair, only the Vorbis users requested albumart. FLAC users > should in theory be able to use the tag too if they want, but this > wouldn't be something we'd see in other codecs like Speex and Theora. This is a minor point, but FLAC users can already do this using METADATA_BLOCK_PICTURE (which
2012 Apr 17
1
command line perl tool to create ogg/Vorbis picture comments
On 14 April 2012 23:40, Ian Malone <ibmalone at gmail.com> wrote: > On 14 April 2012 23:34, Ian Malone <ibmalone at gmail.com> wrote: > >> http://pastebin.com/xXhPyZuQ > >> ./jpegtoblock.pl ?-i DSCN7376.JPG -o flacblock > >> You'll need to add the "METADATA_BLOCK_PICTURE=" which makes it into a >> comment file yourself. >> >
2014 Feb 12
2
[user] coverart and other tags
On Wed, 2014-02-12 at 14:29 +0000, Ian Malone wrote: > On 12 February 2014 13:02, Alice Wonder <alicewonder at shastaherps.org> wrote: > > Hello, > > > > I am new to using opus but so far I really am loving it. At 16kbps > > spoken content sounds fabulous. > > > > I am using opusenc on 64-bit linux - mostly with flac input. > > > > The one
2009 Jul 23
2
Fixing ogg vorbis corruption caused by bad metadata
Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Martin Leese wrote: >> Anyway, calling alloc()s with no corresponding >> free()s is a memory leak. Not good code. > > The alloca() function allocates space on the stack and > that allocation is automatically freed when the function > that did the allocation returns. > > The Linux man page is quite
2019 Jun 21
1
support free WEBP images in Opus files
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
2019 Jun 21
0
support free WEBP images in Opus files
Ogg files can have multiple COVERART or METADATA_BLOCK_PICTURE tags without a problem, though. METADATA_BLOCK_PICTURE is part of the FLAC spec, not OGG (and definitely not Opus), and you can have as many METADATA_BLOCK_PICTURE blocks as you want, so even if each can only store a single picture I'm very unclear about what the problem is? Opus isn't related to its containers, though, those
2018 Apr 17
0
FLAC and external file attributes
Martin Leese wrote: > Just so it is clear in my own mind. > > You are offering to add support for extended > file attributes to flac, the command-line > wrapper around libFLAC to encode and > decode .flac files. Presumably such support > would reside in libFLAC, and so libFLAC++ > and metaflac should also be updated. (Not > sure whether the various music player input
2008 Oct 14
1
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