search for: probob

This comes from Indymedia audio list, Whamb! should probobally be listed on the vorbis.com software pages. ----- Forwarded message from nathaniel t <vsea75@hotmail.com> ----- The whole world doesn't use Linux or Windows. Some tiny fraction of computer users use Macs. I didn't realize until yesterday evening how difficult and mysterious...

> For a lossless codec, the luxury of a "small number of useful formats" > may not be advisable. I can't tell you how many times I've had some raw > data and been completely unable to play it with e.g., mplayer, because > mplayer did not have an apporpriate fourcc. And mplayer has made up many > of their own non-standard fourcc's (which not even all of mplayer

I've spent three days tracking this bug down.. I have yet to find how to fix it in the code, tho I do have a workaround which proves the nature of the bug. Sorry for the somewhat-overkill nature of explaining this bug, but some people have been doubting it so I'm going to give the evidence nessesary to prove the nature of it. If you send page-aligned data to libshout (via shout_send) it

I've spent three days tracking this bug down.. I have yet to find how to fix it in the code, tho I do have a workaround which proves the nature of the bug. Sorry for the somewhat-overkill nature of explaining this bug, but some people have been doubting it so I'm going to give the evidence nessesary to prove the nature of it. If you send page-aligned data to libshout (via shout_send) it

...shout.send(data) > self.page=newpage > return I was still sending it the raw data, but in a loop so it was doing the whole broken record thing. that tipped me off, looked back, figured it out.. <p>The bug has nothing to do with libshout I think, maybe, but it's more probobal with libvorbis. The reason it was not crashing with strait up data but was segfaulting with page-aligned data was not because it was page-aligned but because I was also changing the serial number.. with the first stream being # 0. Apparently, if I bump the initial serialno to 1 it works great....

Hi I'm actually running an icecast server to broadcast voice . I'm not broadcasting music at all . Would it be better for me to use speex ? Is there an icecast-like broadcast server for speex ? Would there be a way to read the braodcast stream under windos and MacOs and Linux ? ( Winam or else ... ) Thenks inadvance ... --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg

Can I change the wiki? The box claims it plays oggs, the tech. specs. in the booklet claims it plays oggs, *some* places on the website claims it supports oggs, but it doesn't actually play my oggs. Can I move it to a "misadvertised" section, or a "rumours" section, or what can I do to indicate this to other people, so they don't accidentaly buy it? Hugo

...ing so. If the bits can be provided which allow several hundred (or thousand) possible formats, by combining interlaced vs non-interlaced, chroma subsampling and methods thereof, colorspace, packed vs planar, and channel bit depths, and within this generic set all of the common and uncommon-but-probobal formats are covered, I think our job will be done. Just because the codec supports it, doesn't mean that every application which uses the codec must support all the possibilities. By making the data definition generic we allow more re-used code (ie, for colorspace converters) and preven...

Hi, Quick note: In case anyone has not heard, Nullsoft, the people behind Winamp, have seen fit to develop their own multimedia container format. It can hold any kind of data, but their primary codecs are MP3 for audio and VP3 for video: http://www.nullsoft.com/nsv/ I and a few other people are still working out the details of the format:

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

In case anyone is interested, there is a great online music store at allofmp3.com that features $0.01 (USD) per Mbyte download. Since they are based in Russia, they pay very low royalties. The kicker is that they encode to your requested format, including ogg/vorbis at whatever quality or bitrate setting you want. Downloading legal ogg's to my iRiver iHP-120.... Oh, the bliss.....

...Ogg Vorbis stream, one would also have to change the encapsulation. Tools to port Ogg Vorbis from Ogg1 to Ogg0 would be fairly trivial, as it'd just take the two granule fields of the page header and add them together to get the Ogg0 granulepos. If this proposal is sound, then there should probobally be a discussion about potential other improvements which could be made at the same time, tho I think we should keep in mind that Ogg0 has proven to be damned stable and useable over several years now. IMHO, this is the first case I've seen where Ogg0 has not been an optimal container f...

...an be generically programmed. Being as there's less than 20, it may make sense to simply define these sets on their own, giving the 6 bits over to "data format" and make these part of the spec. As far as mapping to other codecs, it really doesn't matter, since there'll probobally be a table which says "map to this arrangement". Mapping to maximum 32 would only require 5 bits, if we wanted to condense this list to index#'s, gaining another format bit for something else... in the current spec draft, the top bit is used for interlaced flag, the second for...

> > FourCC is a codec identifier, nothing more. It's four letters which can > be > referenced against a table to see what codec it is, it's a standard used > by RIFF > (aka, wav and avi) and older Macintosh formats, and in my opinion, its > obsolete. > While it's true there are a bunch of FOURCC's that represent non-raw formats like DIVX etc, the ones

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

Here's a shot at a list of fields: // High level data Displayed Width&Height Stored Width&Height Aspect Ratio (Fractional) Frame Rate (Fractional) FourCC (Optional, set to zero to use values below) Colorspace (enum, R'G'B', Y'CbCr, JPEG (not sure proper name), etc) // Subsampling data U Channel X Sample Rate (Fractional) U Channel Y Sample Rate (Fractional) U Channel