similar to: ogg/flac and winamp plugin

On Tue, Nov 20, 2001 at 02:18:16PM +0100, smoerk wrote: > how could i play ogg/flac files? > > would it be possible to add flac support to the ogg libaries? > > i would like to stream ogg/flac files over an icecast2 / jroar server > :). What would be required is support for ogg/flac in the streaming client (and perhaps in the server, depending on how sophisticated it is), by

is there a solution to stream flac files? maybe it's possible to stream a ogg-flac file through the icecast2 server, but is ogg-flac working? smoerk

I agree, but the idea behind the OGG formats is to build patent free codecs. Is FLAC really patent-free ? And does the OGG team agree to include FLAC in their specs ? smoerk wrote: > I agree. I think Ogg/Flac does not make sense, if it's not in the > official distribution. the benefits: > > - many ogg players could play flac > - flac could be integrated in oggenc (oggdrop)

how can i convert a flac file to an ogg/flac file without decoding/encoding?

well, don't get me wrong, I am not generally opposed to progress, but speaking as a coder of source clients, providing yet another authentication mechanism is a bit frustrating.... I guess it wasn't too bad having to deal with Shoutcast/Icecast/Icecast2 specific connection protocols (yes they are ALL different!) but I am NOT going to support Shoutcast/ICecast/Icecast2 (ICE

Have you considered trying to have FLAC become an official part of the Ogg project? Ogg has Vorbis but no lossless codec, and FLAC is already production quality. You've already written the code to wrap FLAC in an Ogg bitstream. Ogg Squish seems to be abandoned, and it would be a grand waste of effort to revive it when FLAC already works so well. The Ogg people would be much better off

I've developed a function for updating Flac metadata blocks inside Ogg files. Obviously it is desirable to use padding so that most edits don't require rewriting massive files. Although the flac encoder creates a padding metadata block by default in Ogg Flac files, this appears to be useless. When packets on an Ogg page change size, the page size may change by as different amount, hence

Hi all, I've made a test release for Ogg DirectShow Codecs. You can find it here: http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15035.exe The problem is that I get a HEAP Corruption detected at: void FLAC__bitreader_free(FLAC__BitReader *br) { FLAC__ASSERT(0 != br); if(0 != br->buffer) free(br->buffer); The call stack is: >

I just uploaded flac 1.0-1 to Debian unstable; it should appear in the archives tomorrow. In order to get things to work correctly with libtool 1.4, I had to apply the following patch: --- flac-1.0.orig/ltmain.sh +++ flac-1.0/ltmain.sh @@ -1862,6 +1862,7 @@ else # We cannot seem to hardcode it, guess

--- Christian Weisgerber <naddy@mips.inka.de> wrote: > Josh Coalson <xflac@yahoo.com> wrote: > > > Basically what I want is configure.in determination of > > basic machine type (intel/compatible, alpha, ppc), then within > > that (say intel) the code will detect variants like MMX, SSE, > > and use the right routines. > > Please include a way to

Hi folks, I'm developing ogg streaming server JRoar(http://www.jcraft.com/jroar/). At present, two JRoars are running at following URLs, * http://ogg.radiostudio.org:8000/ * http://61.207.105.109:8000/ and you will find some streams on them. If you have ogg vorbis player, please try them. The newest source code is available at http://www.jcraft.com/jroar/jroar-0.0.5-pre8.zip JRoar has

could i play a flac with a cuesheet metadata block in winamp and jump to the included track marks or doesn't the winamp plugin not support this feature?

Sorry for the somewhat off-topic post, but while we are on the subject of flac, here's my question: Is the current version of ogg flac (encoded with flac.exe from the official flac website) some kind of beta implementation or is it a fully compatible release that will continue to be supported by future applications? The reason I'm asking is because I get the following error message when

I have just released a source distribution which is the candidate for the 1.0.3 release. At this time I would ask anyone who is willing to help test it to do the following: 1. download the tarball and unzip it: http://prdownloads.sourceforge.net/flac/flac-1.0.3_beta-src.tar.gz?download 2. do ./configure && make && make check This will build all code and run all the tests.

All, I have just finished uploading the source release for FLAC 1.0.4 beta to Sourceforge; there are no binary releases. See the included doc/html/news.html for the changes since 1.0.3; there are quite a few. http://prdownloads.sourceforge.net/flac/flac-1.0.4_beta-src.tar.gz?download Please beat up on this as much as possible in the next week or two and try and turn up bugs. Here's a

libFLAC 1.1.2 I'm using an OggFLAC_seekable_stream_encoder to create an OGG/FLAC file. I'm seeing that the STREAMINFO is not being written when the encoder is finished. I'm seeing that, for whatever reason, although the previously written data is read back in, simple_ogg_page__get_at () is failing when checking the CRC at the end of the function. As far as I know, I have

Josh Coalson wrote: > --- Christer Palm <palm@nogui.se> wrote: > >> >>I'd be happy to put some effort into making that happen, but after >>having looked at the code as it currently stands I realize that this >>would require some quite substantial changes, and it would probably >>be >>wise to have an open discussion about whether and how such

Rafael Velasquez wrote: > I have installed libflac via synaptic, the version is 1.2.1-3. If you want to compile some other code against libflac, you also need to install libflac-dev. However, the code you posted a link to does not compile on it's own, it requires other code in the source code tarball. Erik -- ---------------------------------------------------------------------- Erik

> Are the changes for FLAC/ordinals.h really necessary? Yhe FLAC/*.h > header files specify libFLAC's public API. In a previous thread on > this mailing list back in February we decided that for compilers > that didn't supply <stdint.h> the developer should supply something > suitable. Here's the commit: Yes, they are necessary. Here is the rationale 1)

On Sat, Jul 21, 2001 at 04:06:14PM -0400, Matt Zimmerman wrote: > Argh. Maybe libtool will have to get involved after all. I'll work on it > this afternoon. I think I give up. automake and libtool assume that the compiler will be able to assemble stuff, and compilers don't generally understand NASM input. I don't like the strip_fPIC bit, since just about anything that could