similar to: How to check/test existing FLAC stream for Subset?

> 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

Many Thanks for your answer. Actually quite a few 'ifs', 'maybes' or 'shoulds'... ;-) I have tried most of them (except liquidsoap). However, even the mentioned apps like RadioDJ or Mixxx do NOT support meta data changes via the encoder (they all use the admin interface)! And as you correctly pointed out: none of the reference encoders support this. Not even the FLAC, OGG

Cristian Adam wrote: > On Wed, Feb 25, 2009 at 2:23 PM, Brian Willoughby <brianw at sounds.wa.com>wrote: > >> A better suggestion might be to start with libFLAC, optimize as >> needed, and then submit the optimizations back to the FLAC project >> where they will be more widely useful. >> >> But that's just my opinion. >> > > I agree. This

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 am a software developer myself. We develop a Radio Automation System/Broadcasting. Hence we are using the reference encoders. For OGG there is LUCKILY still the admin interface working to update meta data mid-stream. That is why my post is related to the other ogg based formats: FLAC and OPUS! Tractor Pro is btw not supporting FLAC or OPUS and alao uses the admin update interface! As such

Thanks for your clear answer. I'll try to contact the OGG, FLAC a Opus encoder developers at xiph.org. As it currently seems, that there is no direct support for chained streams on the 'client-side' (encoder side) when using the reference encoders as provided by xiph.org. As such I find it a bit odd to have no 'out-of-the-box' solution available at all. Even if all/you say:

Thanks for the info, Dave. Speed is a very important feature, but there might be some risk choosing the FFmpeg decoder. They've had trouble with their encoder in the past, which tells me it's possible your users might one day run into a valid FLAC that the FFmpeg decoder won't handle correctly. A better suggestion might be to start with libFLAC, optimize as needed, and

I am also philosophically opposed to changing the specification. That said, there's nothing wrong with adding a note to the specification about the common implementations, particularly the reference library. Then, future developers will know both the precise specification and still have the warning that they risk incompatibility by deviating from the reference implementation. I own devices

Thanks for all the info - I was able to find exactly what I was looking for here: http://codecs.ex-sounds.net/ogg/vorbis/oggenc/ As for what I'm up to, I have a memory-limited port of the Tremor Vorbis decoder that I want to test on some older vorbis encoders for backwards compatibility purposes. Nothing too nefarious. ;) On Thu, Aug 6, 2009 at 8:59 PM, Silvia Pfeiffer <silvia at

For what its worth, there are archives of prebuilt ffmpeg version of ogg. http://ffmpeg.arrozcru.org/builds/ <http://ffmpeg.arrozcru.org/builds/> On Wed, Aug 5, 2009 at 6:58 PM, Ralph Giles <giles at xiph.org> wrote: > On Wed, Aug 5, 2009 at 8:11 AM, Ethan Bordeaux<ethan.bordeaux at gmail.com> > wrote: > > > Hi, I was wondering if there's anywhere I could find

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

Using FFmpeg, I can stream to a file on disk okay: c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek High Definition Audio)" -c:a libopus -ac 1 -b:a 32000 live.caf But, if I add Icey metadata, FFmpeg throws errors: c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek High Definition Audio)" -c:a libopus -ac 1 -b:a 32000^ -ice_name

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

Hi Philipp, While you might logically/theoretically be right with what you say, it is not really practical and unfortunately not user friendly. Let me try to explain my standpoint: Most users do use ICEcast to stream a continuous stream, e.g. they stream a live DJ or radio program. I.e. they setup a single encoder on a single audio stream. Still this logical stream contains different tracks being

Please help me understand what values of FFMPEG's "compression_level" preset generate subset FLAC stream and what not-subset? Default value of compression_level for FFMPEG's FLAC encoder is 5. FLAC specific encoder parameters: Encoder flac [FLAC (Free Lossless Audio Codec)]: Threading capabilities: no Supported sample formats: s16 s32 FLAC encoder AVOptions:

I tried to encode two minutes from an AVI DV file 720x480: ffmpeg latest release produces a FLV 320x240 25fps 360k video 40k audio in about 45 sec. ffmpeg latest release produces an OGG 320x240 25fps 360k video 40k audio in about 1:20 sec. ffmpeg2theora the same in about 2 minutes or more. The FLV quality it's quite good, some dropped frames maybe. I was wondering to know if ffmpeg team

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

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

wow, thanks for the quick reply! > > My suggestion: try out the ffmpeg flac thingie since that speed > improvement is unreal in compare to the normal flac :) > > > Stefan Thanks for the suggestion - I'm reading the ffmpeg changelog and feature list right now, and it appears that it only supports flac decoding not encoding and decoding - is this because the documentation is

On 02/20/2017 06:06 PM, Scott Robbins wrote: > On Mon, Feb 20, 2017 at 07:58:22PM -0600, Michael Hennebry wrote: > > >> I have movie player installed on centos 6. >> When I try to play an mp3 file, it complains about the lack of a codec, >> mpeg-1 something 3. >> google hasn't helped. What package do I need? >> Trying to install ffmpeg gets me a no such