similar to: For what FLAC subset was introduced?

I mean that the first statement [Subset streams must use one of 192/576/1152/2304/4608/256/512/1024/2048/4096 (and 8192/16384 if the sample rate is >48kHz).] published on https://www.xiph.org/flac/documentation_tools_flac.html#flac_options_blocksize page IS NOT EQUAL to second statement [The blocksize bits in the frame header must be 0001-1110. The blocksize must be <=16384; if the sample

I'm misleading about FLAC subset constraints... Please help me understand exact FLAC subset limitation.

Any progress? > I agree. Please keep up informed. >> FLAC__format_blocksize_is_subset() was introduced by commit #8ab0138 >> (https://gitorious.org/flac/flac/commit/8ab013837d379d3d1fa84eac5420faec41852fd7) >> over 5 years ago and available in the latest stable release 1.3.0. >> >> It would be nice if the official FLAC documentation used common >> adopted

Yes, this is such a case. However, implementing this in a future encoder/decoder would break compatibility with most (likely all) existing decoders, and only in some very, very rare cases where the material is such that the encoder chooses to use negative shifts, which makes it even harder to troubleshoot. Furthermore, as this can only be used in very rare cases, there is no benefit from allowing

I think you've found a bug, Bart. flac 1.2.1 did not have any FLAC__format_blocksize_is_subset() function, so the source you're seeing in format.c must be new. If the format documentation you linked to is correct, then either the specifications are self-contradictory, or the code is not implementing the subset checks as described. My interpretation is that blocksize bits of 0110

>>>>>>>>> I'm misleading about FLAC subset constraints... Please help me >>>>>>>>> understand exact FLAC subset limitation. >>>>>>>>> >>>>>>>>> From https://www.xiph.org/flac/documentation_tools_flac.html#flac_options_blocksize: >>>>>>>>>

> check the resulting file for subset blocksizes, sample rates, bits per sample, LPC filter order and rice partition order. That's all parameters that I need to check? FLAC tools have a lots of warnings about non-subset files during encoding, but unfortunately don't have easy way to check/test existing FLAC stream for subset compliance. "flac -a" generates the big text file

I mean that the first statement [Subset streams must use one of 192/576/1152/2304/4608/256/512/1024/2048/4096 (and 8192/16384 if the sample rate is >48kHz).] published on https://www.xiph.org/flac/documentation_tools_flac.html#flac_options_blocksize page IS NOT EQUAL to second statement [The blocksize bits in the frame header must be 0001-1110. The blocksize must be <=16384; if the sample

Finally, does this mean that: 1. Now any block size from interval [16, 4607] is subset, e.g. 588? 2. Now any block size from interval [16, 16384] is subset, (only) if sample rate > 48 kHz? And the third is the most interesting question: 3. Now not only constant (fixed) block size stream can be subset, variable block size stream can also be subset, (only) if minimum block size of this stream

All, This mail is a survey to get some feedback about changes to the FLAC Subset (see http://flac.sourceforge.net/format.html#subset). FLAC hardware support is growing. The PhatBox was the first but now there's the Rio Receiver, and FLAC is being worked into the Audio ReQuest box, among others. Based on feedback from this development I am contemplating restricting the subset a little more.

I think I have something misconfigured regarding voicemails. They work great, I have this setup: Sip.conf [ext1] Context=phones Mailbox=201 Voicemail.conf [home] 201,password,name,email@mail Voicemail delivery and all works great but when I check sip extension ext1 (analog phone using a Granstream ATA 286), the stutter tone signaling message waiting does not work. Anything wrong with

I've got the latest asterisk 1.8 running on a Netra X1 with Solaris 10 u10. The system itself is happy and phone calls (between two parties) seem fine. Unfortunately, when a caller listens to a Playback recording, there seems to be moments of stutter - perhaps 1 second of stutter for every 10 seconds of Playback. The stutter is not consistent at the same point of the playback file. To

On Mon, Dec 1, 2014 at 10:40 PM, ???? ?????? <bart.gopnik at gmail.com> wrote: > Please help me solve the following problem: > > FLAC tools have a lots of warnings about non-subset files during > encoding, but unfortunately don't have easy way to check/test existing > FLAC stream for subset compliance. > > "flac -a" generates the big text file that has

Hi, We would like to use the OPUS codec @ 16 kHz sampling rate and max 32 kbps. What about implementing an OPUS coder and decoder in an FPGA? Has this been done? Would either coder or decoder more suitable for FPGA implementation? Best regards Fredrik Bonde -------------- next part -------------- An HTML attachment was scrubbed... URL:

May be I have fiddled too much with my sipura settings but I can't get it to give the stutter tone when there is a new voice mail waiting on the asterisk box. I can either get a stutter tone all the time or not at all. Anyone got this working. Thanks Chris

I dont recall the SPA-941 playing a stutter tone in the previous firmware but it is driving me nuts, anyone know where to turn it off? Kerry Garrison Director of Technical Services Tech Data Pros - Orange County's Mobile IT Service Provider (949) 502-7819 x200 - <mailto:kerryg@techdatapros.com> kerryg@techdatapros.com <http://www.techdatapros.com/> http://www.techdatapros.com

Just to make sure, what's the goal here? Is the goal 1) to have a fast Opus implementation or are you 2) looking for an interesting FPGA implementation project? If 1), then an FPGA is most likely not necessary since Opus is not computationally expensive. If 2), then it depends on the desired size of the project and the desired quality. The simplest encoder possible is indeed simpler than the

I would also add that the "level" is only relevant to the reference encoder, as it is an alias to quickly set a number of parameters. Other encoders might make different choices. Also, I haven't looked in details at how the encoder works, but I think it is based on heuristics to decide which is the best compression method for a set of samples, and I'm not sure that it would give

Hi, I'm developing a flac decoder in an embedded environment. I have it fully up and running but I am trying to optimise the performance vs. the power it takes to decode the stream. Using the reference decoder code with a few optimisations for the hw I'm on I experience quite a difference in mips depending on the level. For instance, on a 192kHz/24 bit file the difference is almost

Hi all, When trying to better understand the way LPC exactly works, I stumbled upon something which, after some digging, was already reported and (partly) fixed: https://sourceforge.net/p/flac/bugs/424/ Apparently, the FLAC specification has a LPC shift that can be both positive and negative, but the encoder specifically makes sure that only positive shifts are encoded and the decoder only