similar to: Facing problem of decoding FLAC

Hi, I've got two SIP clients, one is X-Lite on NT, the other is KPhone on Linux and when I try either the echo test or voicemail demos, they fail to send any audio. They are both set up as type of "friend" in sip.conf so that they can send and receive calls. Using an IAX client like Gnophone, I have no problems. The troubling thing is that I'm almost certain that this was

Dear all, Though this is not LARTC related question, finding no other help I am forwarding this question for this group. Hope some GURUZ will help me. I want to authenticate my lan users through pppOE. I am using rh 9.0 box as my gateway. How / Which software do i use on my linux box to provide pppOE service and in client end win98/2000/Xp which software do i use?

Hi guys, Thanks Matt for your prompt response about the C++ problem, its working great now! Again for my "virtual cdplayer", I am wondering if its possible to stop decoding within a large file, at the end of an exact sample? ie. I wish to play a song in the middle of a flac'd cd. Using the file decoder, I can seek to the start of the track(index 01 of the cds TOC), but I then want

I'm attempting to decode part of a largefile flac whose seektable is broken or missing and the file is shorter then it's supposed to be, when I use 1.1.2 it decodes fine, when I use 1.1.3 it fails flac --decode --skip=719:58.0 --until=1024:58.0 -o \/home\/sbh\/work\/hs\/out.wav \/mnt\/ss\/sdb\/Sound\/Recording\/2006\-11\-29\/in.flac out.wav: ERROR seeking while skipping bytes

I'm attempting to decode part of a largefile flac whose seektable is broken or missing and the file is shorter then it's supposed to be, when I use 1.1.2 it decodes fine, when I use 1.1.3 it fails flac --decode --skip=719:58.0 --until=1024:58.0 -o \/home\/sbh\/work\/hs\/out.wav \/mnt\/ss\/sdb\/Sound\/Recording\/2006\-11\-29\/in.flac out.wav: ERROR seeking while skipping bytes

On 12/11/06, Josh Coalson <xflac@yahoo.com> wrote: > --- Avuton Olrich <avuton@gmail.com> wrote: > > I'm attempting to decode part of a largefile flac whose seektable is > > broken or missing and the file is shorter then it's supposed to be, > > when I use 1.1.2 it decodes fine, when I use 1.1.3 it fails > > > > flac --decode --skip=719:58.0

Hi! I've been using a little C++ program I've written to encode flac files. The program does this in the usual way (I think), by inheriting a class from FLAC::Encoder::File, and passing it chunks of raw samples through process_interleaved()... Anyway, the program works beautifully, and I've now decided to try and add some metadata to the encoded flacs. Eventually, there will be vorbis

Op zo 13 okt 2024 om 02:16 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > I cannot find any clues in the documentation how to write a > seektable/reserve space for it. > Can someone help me out? > There's actually quite a lot of documentation for this. Please review https://xiph.org/flac/api/group__flac__stream__encoder.html#ga80d57f9069e354cbf1a15a3e3ad9ca78

Hi Martijn, Am 13.10.24 um 21:00 schrieb Martijn van Beurden: > > There's actually quite a lot of documentation for this. > > Please review https://xiph.org/flac/api/group__flac__stream__encoder.html#ga80d57f9069e354cbf1a15a3e3ad9ca78 > > I quote: >> SEEKTABLE blocks are handled specially. Since you will not know the >> values for the seek point stream offsets,

I have an asterisk installation at a client, it's quite simple. Basically it's an asterisk downloaded from CVS about a week ago, with 3 Zaptel FXO cards (the digium ones) and 10 Grandstream Budgettone SIP phones ... Every now and then, especially when a call is ringing and not picked up immediately, Asterisk quits with a segmentation fault error. IT seems quite inexplicable, my dialplan

I think there is another major issue for me: In METADATA_BLOCK_STREAMINFO the field for the length is only 36 bit, that's not even half an hour at 40 MHz sample rate, resulting in that the encoder sets it to 0 for longer captures. In the seekpoint the sample number is 64 bit, which is more than enough. But how does the decoder handle the seektable when the total number of samples is unknown?

Op zo 13 okt 2024 om 22:33 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > Is the seektable written at the beginning of the file in the metadata > block or can there also be a second metadata block at the end? > Only at the start of the file. > > If it's at the beginning, would it possible to reserve space for N seek > points and during encoding remember

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

>> I'm jumping in on this thread to make a few remarks about the spec. I >> implemented a FLAC decoder by only looking at the spec, and I have a few >> notes that would have saved me a lot of time if the spec had mentioned >> them. They are obvious in hindsight, of course. >> >> * If the channel assignment includes a difference channel, then the >>

(I am not on this list, please CC me manually if necessary) On Fri, Mar 15, 2002 at 11:47:15PM -0500, Asheesh Laroia wrote: > Are you sure it's not your compiler? That's the first thing I would > check. I know that RedHat is famous for including broken pre-releases of > GCC in their distributions since 7.0. FUD. Please stop that, it makes you look unprofessional. Until you can

I've checked in code that supports a new metadata block called SEEKTABLE. Basically, it is an optional, arbitrarily-long list of seek points, by sample number and stream offset. I also added command-line options to flac so you can specify seek points by specific sample number and/or a specific number of evenly-spaced seek points. The table cost about 18 bytes per seek point. This seems to

I would like to know if my vision of things is correct about frame structure. -------------------------------------------------------- Frame header -------------------------------------------------------- Subframe1 header|Subframe1 content| -------------------------------------------------------- Subframe2 header|Subframe2 content| --------------------------------------------------------

As far as I can tell I've found a serious bug in the command line flac encoder :( I have created many hundreds of flac files and I was very annoyed to discover that the XMMS flac plug-in had intolerably long seek times, but since that had been mentioned on this list a bunch of times without anyone actually investigating, I thought I had better actually find the BUG which causes this. 1. I

Hello, I'm using flac to compress s signal data during capture. The sample rate is almost a thousands time higher compared to audio (40 MHz), resulting in a lot of data very quickly. I'm using the C API in my capturing application (mostly copy&paste directly from the example) and it works so far, but unfortunately for longer captures there is no seeking information. How can I tell

Op di 15 okt 2024 om 21:27 schreef Alistair Buxton <a.j.buxton at gmail.com>: > > I would like to see this kind of thing put into a secondary metadata block aimed specifically at SDR. This could be completely ignored by regular audio players - these files are not meant to be listened to anyway. I could probably figure out how to implement that, I even started looking into it once, but