similar to: Ogg FLAC

--- Ingo Ralf Blum <ingoralfblum@gmx.de> wrote: > > currently flac sets all granulepos members of the ogg pages to 0, > when > > embedding a FLAC stream into an Ogg file. Is it possible to change > this > > behaviour to use a more reasonable value, e.g. the bytes written so > far. > So > > when the first packets is 1000 bytes long it gets the granulepos

Hello everyone, I was just browsing through some video capturing websites/forums and saw some people complain that there was no lossless codec available to encode audio in AVI files. I thought that FLAC would have one but it doesn't seem to be the case. As it's a popular demand (now that hard drives are inexpensive, people can record hours of video/audio without any loss and then

--- Ingo Ralf Blum <ingoralfblum@gmx.de> wrote: > Hi, > > > sorry about that... it sounds like a good idea but I don't > > know what the right metric would be (bytes written, sample > > number, etc). I was going to forward this to vorbis-dev > > but haven't yet. > > If you see the whole thing from a perspective of a filter graph, like >

Hi, The FLAC__stream_decoder_flush doesn't change the state, but when I play a stream and reach the end I have to do a FLAC__stream_decoder_reset and reread the metadata instead of simply a FLAC__stream_decoder_flush. This is because the stream state, which indicates the end of the stream, is not changed. Is there a reason, for the state not being reset to

Matt Zimmerman wrote: > > As I understand it, the current Ogg/FLAC implementation simply wraps the Ogg > bitstream format around a normal FLAC stream, thus not utilizing the > features of Ogg, and duplicating various bookkeeping data. If the Ogg folks > were to spec out a FLAC-based codec for Ogg, it would likely look different > from the current implementation. > Right.

HI Josh, I'm starting now to compile the ACM codec. I don't know how long it will take, since I do it in my free time, but I guess it will not take to long. About Mark Powell's comment, with an ACM codec there will be a lot of Windows GUIs for FLAC. I'm writing this message to talk about the FLAC format. The GUIs for the Audio Codec Manager, including Winamp and Windows Media

Hi, The stream decoder follows a push model, however, I need a pull model decoder, like, for example, implemented by the Vorbis libs. For this I simply save the pointer to the audio data in the read callback and acces the data lateron after the call to FLAC__stream_decoder_process_one_frame returned. Is this safe? Can I assume that the internal buffer is not freed, when

Hi, these two values can be stored in the stream info metadata block as well as in the header of each frame. This leads to some questions. - Are these values supposed to change during playback, e.g. first comes a frame with 2 channels, then with four and the next switches the bit count from 16 to 8 and so on? - There are methods to retrieve these values from the stream decoder. Unfortunately

Is there a reason for having the FLAC__stream_decoder_get_input_bytes_unconsumed function private. This function is required now by two of my filters for seeking and buffer managment, when not all data is available from the beginning. Regards, Ingo

Hi, I'm the main author of Speex (http://speex.sourceforge.net), an open-source speech codec that uses Ogg for file storage. I'd like to have feedback on the way we store Speex data in Ogg files to make sure we do the right thing. The Speex documentation can be found at http://speex.sourceforge.net/manual/ but here's the part about Ogg: <p><p>Speex bit-streams can be

Hi, I have a problem when I try to open a file, which is not a FLAC file. When I open a non-flac file with the stream decoder API, one of the first things called is FLAC__stream_decoder_process_metadata, which itself calls stream_decoder_find_metadata_. Unfortunately the non-flac file contains some content, which leads to the state set to FLAC__STREAM_DECODER_READ_FRAME. However in

On Sat, 2006-07-15 at 14:35 -0700, Ralph Giles wrote: > On Sat, Jul 15, 2006 at 02:17:22PM -0500, Joe Wreschnig wrote: > > > I'm working on support for tagging Speex files for Mutagen[0] and part > > of the specification at [1] is confusing me. It says the first page > > should have granulepos 0 and packetno 0. Does this really mean page > > sequence number 0,

(Sending again after subscribing, I guess the moderator is on vacation.) I'm working on support for tagging Speex files for Mutagen[0] and part of the specification at [1] is confusing me. It says the first page should have granulepos 0 and packetno 0. Does this really mean page sequence number 0, since the Ogg format doesn't number packets? If it doesn't mean page sequence number,

dear list, i am trying to write a small program which reads an ogg file and writes it to another ogg file (and changes serial number, granulepos etc on the fly). reading the ogg file is ok (ogg_sync_pageout, ogg_stream_pagein, ogg_stream_packetout). but writing the file doesn't work - the granulepos and page structures don't match with the original file. here's what i am doing.

2008/11/26 David Flynn <davidf+nntp at woaf.net>: >>>> http://trac.annodex.net/changeset/3801 >>> >>> I'll test this shortly. > > Ok, i've tested muxing some audio and video together and that works fine. > woo. great, thanks :-) So the last remaining tool to check is oggz-chop. I at first assumed it would not work with Dirac's granulepos,

Hi, I'm wondering if the Dirac granulepos parsing in liboggz and display in the oggz tools is currently correct, as I'd like to do a release of these soon. A couple of days ago David Schleef mentioned there were some problems. David, is that currently true (ie. since David Flynn's recent updates to support Dirac), and if so could you please explain what the problems are, or point me

2008/11/14 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: >> I'm wondering if the Dirac granulepos parsing in liboggz and display >> in the oggz tools is currently correct, as I'd like to do a release of >> these soon. > > I believe it is -- although if correct support in the rest of the >

Hi, >That's what I wanted to say a month ago. Mr. Blum, I'm really sorry for misunderstanding you. My mistake. I choose an ACM codec because it's the only option that works on every Windows Platform, and since the DirectShow has a generic wrapper that allows it to use ACM codecs, it appeared a good idea. I didn't note that the file format was going to be a problem. But I think

On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: > I'm wondering if the Dirac granulepos parsing in liboggz and display > in the oggz tools is currently correct, as I'd like to do a release of > these soon. I believe it is -- although if correct support in the rest of the liboggz tools is required, a little more work may need to happen. > Here's some

2008/11/21 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-21, Conrad Parker <conrad at metadecks.org> wrote: >> 2008/11/15 David Flynn <davidf+nntp at woaf.net>: >>> On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote: >>>> It seems oggz chop, merge and sort will need some attention to deal >>>> with the Dirac