similar to: Fixing ogg vorbis corruption caused by bad metadata

Displaying 20 results from an estimated 4000 matches similar to: "Fixing ogg vorbis corruption caused by bad metadata"

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 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
2013 Jul 23
2
Metadata
Brendan Bolles wrote: > Hey everyone, according to Wikipedia's 4-year-old information, there is no > standard for putting metadata into an Ogg file. True. > That metadata must be > included in the codec. More generally, in a stream in the Ogg file. Codecs are streams, but so are things like Ogg Skeleton. Information about Metadata has been collected together in the Xiph Wiki
2009 Jun 28
6
Tidy up of XiphWiki VorbisComment page
I have been tidying up the VorbisComment page in the XiphWiki. The problem with it was that it was a mixture of proposals and discussion of those proposals. This made it difficult for implementers to see what to implement. The problem section is: http://wiki.xiph.org/index.php/VorbisComment#New_ENCODER_field_name_proposal This is a mess, and all I could do was add attributions to the
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
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
2018 Dec 11
2
New ID registration
"Kurosawa, Taku" wrote: > Hi Martijn, > > Sorry for the late reply again, > The application we are preparing this time is not exactly similar to > Replaygain. > > Replaygain as we understand is something which normalize the loudness at > content provider side, but our application takes different approach. It is > designed to normalize the loudness at player
2015 Nov 30
2
Proposal for Ambisonics format in vorbis comment.
"Gabriel I." wrote: > Greetings, > > I apologize if I posted this in the wrong list, I wasn't sure where to post > it, but seeing as the tags are called "vorbis comments" I thought vorbis, > rather than ogg-dev, would be the right choice. (actually, I'm not even a > developer anyway) Hi Gabriel, I doubt whether the Xiph community would promote a
2012 Jun 07
3
embeding xml to ogg
Oleksij Rempel <bug-track at fisher-privat.net> > On 05.06.2012 20:41, Martin Leese wrote: ... >> On 6/5/12, Oleksij Rempel wrote: >> || We need fallowing tags: >> || creation datetime: seconds and time zone should be included. >> || source host: it can be name or guid. to organise created files by >> sources. >> || keywords,events. >> || date
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
2012 Sep 11
1
Patch for Metadata::Padding
Bastiaan Timmer wrote: ... > In a > previous message I mentioned writing some more convenience functions, but on > closer inspection they would either be inefficient or very difficult > to implement. Could you briefly list these, in case somebody else wants to have a go. Many thanks, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web:
2012 Jun 04
3
embeding xml to ogg
"Benjamin M. Schwartz" wrote: > On 06/04/2012 10:50 AM, Oleksij Rempel wrote: ... >> XMP fits to our needs, but it >> looks like there is still no ready documentation about muxing XML to ogg. > > Well then you've already solved the problem. Just store the XMP in a > VorbisComment field named "XMP" (or whatever name you like). This suggestion falls
2012 Mar 09
2
Enhanced Podcasts with Ogg Vorbis (Chapter Marks)
Ralph Giles <giles at thaumas.net> wrote: > On 5 March 2012 01:51, Silvia Pfeiffer <silvia at silvia-pfeiffer.de> wrote: >> I've started the following wiki page: >> https://wiki.xiph.org/Chapter_Extension > > Not webvtt-style '-->' timestamp separators? :) ... > We should also trim leading and trailing whitespace. Silvia Pfeiffer <silvia at
2018 Oct 26
1
Proposal - Extended Channel Layouts in Opus
On 10/25/18, Rodger Combs wrote: > >> On Oct 25, 2018, at 12:47, Martin Leese <martin.leese at stanfordalumni.org> >> wrote: ... >> An alternative approach is to only define >> popular layouts. For more obscure layouts, >> such as 2.1 and Mid/Side, assume that the >> person doing the encoding knew what they >> put in, and so knows what will come
2013 Jul 23
2
Metadata
On 7/23/13, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > On 23 Jul 2013 15:17, "Martin Leese" <martin.leese at stanfordalumni.org> > wrote: ... >> Information about Metadata >> has been collected together in the Xiph Wiki >> at: >> https://wiki.xiph.org/Metadata > > That page is a bit outdated. It has CMML in it which we
2007 Oct 21
3
OggPCM family
Erik de Castro Lopo <mle+xiph@mega-nerd.com> wrote: > Martin Leese wrote: > > So what is "OggPCM"? I started this thread > > because I was puzzled why someone was > > changing a draft instead of the document > > itself. > > The original OggPCM was started by a person who really didn't > lnow what they were doing and wouldn't listen to
2013 Jul 24
2
[OT] Tidy of Wiki Sidebar
I have been tidying up bits of the Wiki. This one is not clear cut, so I decided to seek advice. Also, I wasn't sure where to post this question, so defaulted to ogg-dev. Should Speex and CMML be removed from the Wiki Sidebar at: https://wiki.xiph.org/MediaWiki:Sidebar ? Many thanks, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web:
2009 Jun 21
1
Replay Gain in Vorbis
Wasn't sure whether to post this to <vorbis-dev> or <vorbis>. Have settled on <vorbis-dev>. Where can I find details on how to encode Replay Gain into Vorbis files? On the Wikipedia page at: http://en.wikipedia.org/wiki/Replay_Gain it states: "FLAC and Ogg Vorbis use the REPLAYGAIN_* comment fields." but I can't find any reference to Replay Gain in
2007 Mar 22
3
Code for Ambisonics
Hi, I have posted this three times to the flac-dev, vorbis-dev, and ogg-dev mailing lists. I wanted to see what code there was currently to support Ambisonics. So I downloaded the code from the xiph download page for libogg-1.1.3, libvorbis-1.1.2, vorbis-tools-1.1.1 and flac-1.1.4, but wasn't able to find anything. If it exists then I missed it, so could somebody please point me to it.
2018 Oct 25
2
Proposal - Extended Channel Layouts in Opus
Rodger Combs wrote: > I've run into some issues using Opus with source files in channel layouts > other than the default 8. For instance, 2.1 isn't supported, so I have to > either downconvert to 2.0 or upconvert to 5.1 (which usually involves adding > empty channels, which prevents the playback device from upconverting to the > native layout). > To address this,