similar to: is this list used anymore?

I've been implementing Ogg FLAC support in an editor I'm working on, and I must admit to being frustrated by the lack of support for the codec on the Ogg layer... and this is more than lacking granulepos. The codec's I've worked with, and my own (Writ), use Page 0 for general information about the codec. Specifically, the samplerate, bitrate, quality, number of channels, all

I wish I would have come across this in time for the libogg-1.1.1 release... Maybe I'm doing something wrong but here it is. One FLAC compressed frame becomes one packet when encapsulated in Ogg, and FLAC packets can be much larger than the nominal 4k page size. For CD audio they are usually 10-15Kbytes. Imagine this Ogg stream where the lines denote page boundaries and the x's are one

Hi, I am creating a new ogg stream for theatrical/stage/disco lighting and am having trouble encoding my comment header with the following code in _tp_writelsbint function, it does not write the second byte to the ogg buffer. I am using windows and have created a new win32 library project with visual studio and added my code, what do i have to do to get the function working? Is there a project

Folks, the packets I want to place in an ogg stream are concatenations of two hunks of memory. Rather than memcopy() them into one then pass them to libogg, I patched framing.c to accept iovecs. The unified diff is 80 lines, minus the OS-specific stuff for defining struct ogg_iovec_t - pretty trivial. Is there any interest in it? Or is libogg frozen while all efforts are concentrated on

On Fri, 2006-01-13 at 10:41 -0800, Arc Riley wrote: > I believe this problem was fixed in my branch well over a year ago. > These fixes have not been merged into trunk. > > Checkout http://svn.xiph.org/branches/ogg2-arc > > See if it fixes your problem. I've done bitpacking using this patched > library and trunk/py-ogg2 and it seems to be fine. I'd rather use

Hi everyone, I just landed into the theora planet, as a game programmer, I searched for a free video fomat/codec and the theora choice became obvious. However I experienced rather bad performance (at least from a game programming point of view) After a couple a profiling, I discovered, as previous discused in a post found via Google, that the bottleneck is in the ogg library. An unsane part of the

hi all I found that in the revision 10730 of the libogg2 library it is impossible to do bitpacking. this is due to the implementation of the (at least) two functions oggpack_writeinit() and oggpack_readinit(). they both take an (oggpack_buffer *) as an argument and immediately erase all it's contents: void oggpack_readinit(oggpack_buffer *b,ogg_reference *r){ memset(b,0,sizeof(*b));

I've called for a meeting tomarrow to form a new developer's subgroup named "HyperFish". The purpose of this meeting is to collectivly vision for what Xiph is going to look like a year from now and form a realistic plan to help reach that goal. It's not intended to "take over" projects or assume control over other Xiph work, only to estabish a

I've called for a meeting tomarrow to form a new developer's subgroup named "HyperFish". The purpose of this meeting is to collectivly vision for what Xiph is going to look like a year from now and form a realistic plan to help reach that goal. It's not intended to "take over" projects or assume control over other Xiph work, only to estabish a

I've called for a meeting tomarrow to form a new developer's subgroup named "HyperFish". The purpose of this meeting is to collectivly vision for what Xiph is going to look like a year from now and form a realistic plan to help reach that goal. It's not intended to "take over" projects or assume control over other Xiph work, only to estabish a

Michael Smith wrote: > libogg has two bitpackers; a little endian one and a bigendian one. ok, I didn't see it in the docs at http://www.xiph.org/ogg/doc/libogg/reference.html and didn't look in the header file first. My bad. Is it correct to state that the oggpack_* functions use little endian order, and the oggpackB_* functions use big endian order? Is it safe to mix calls to

it's good you brought this up, I want to finalize the Ogg FLAC bitstream mapping and add it to the docs. currently the way it is done in flac 1.1.0 is not ideal and probably should change. --- Arc Riley <arc@Xiph.org> wrote: > I've been implementing Ogg FLAC support in an editor I'm working on, > and > I must admit to being frustrated by the lack of support for the

Ok maybe it's just my imagination, but it looks like the one-line "duh" fix I committed from Andrej Vakrcka <ander@cauldron.sk> this week DRAMATICALLY reduces distortion in encoded files. Take a look and compair. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to

Hi Folks, FWIW I figured out the /etc/magic file entries for both native and Ogg wrappered Speex, Vorbis and FLAC (attached). YMMV because the fields aren't necessarily in fixed positions in the files, but it works fine for me. Feel free to include it in the Xiph archives or forward it to the /etc/magic file maintainer once you're satisfied with it. John -------------- next part

Arc wrote: > Ok so we cap it to 64bit, since much more than that doesn't make sense (96bit > would be a "long double" C type) On x86 CPUs, "long double" is 80 bits. > I really don't like this idea, but I will entertain, formatting it as follows: > > ID Type Bits > 0 Int 8 > 1 uInt 8 > 2 Int 16 > 3 Int 24 > 4 Int

Alright folks, here's the solution. 1) Keep extensions to 3 letters for audio & video. Except for special situations where the user might be doing a codec specific name. Since the official extensions are 3 letters, those can always be used on any 8.3 device. 2) introduce a new extension .OGV for ogg container video. With a strong preference for Xiph only codecs. (If you want 3rd

Ok guys and gals Monty assigned me as libogg2 maintainer a few weeks ago, with the provision that I get consensus on API changes from everyone. In order to facilitate discussion, and to "move on" vs letting this stalemate hold development at a stand still, I'm setting an initial deadline of this comming Monday, May 30th. If nobody has a strong objection why these API changes

While trying to get other work done on Motherfish-II, I couldn't help but notice that machine load was over *200*, due entirely to the viewCVS CGI. Either we were being DoSed via the cgi, or it's too inefficient to even think about using. Motherfish is a server intended for *core services only*. We've been steadily forgetting that. Core services include CVS, mail and web. They

A large test I ran on flac 1.0 recently finished so I thought I'd post the results. I took about 60 CDs, totalling around 30 gigs uncompressed, and compressed them all using all 10 of flac's default compression modes (-0 through -9). The CDs are of a wide variety of music; I think the only major genres not represented are country and rap (freudian slip). Anyway, the raw numbers: Opt