similar to: 1.21 vs 1.3 encoding speed

Are you sure they didn't change the default encoding level ? I would include some example timings to give a better idea of what "significantly slower" is Wonder if you see same for 44/16 files? > On Jul 25, 2014, at 2:29 AM, Martijn van Beurden <mvanb1 at gmail.com> wrote: > > Hi, > > You might want to report this to the flac-dev mailinglist instead of the

Please cc: the results from dev list back here though I would run some tests on a diff platform but don't have access to my PC for a few weeks Would also be interesting to see what decoding stats you get > On Jul 25, 2014, at 7:38 AM, Scott Brown <scottcbrown at gmail.com> wrote: > > I will post to the dev list, sorry about that. > > To give an idea, though, at flac

Hello, I'm on a Mac and I'm noticing that encoding via the flac command line is significantly slower with version 1.3.0 than 1.2.1. I'm encoding a 24/96 file to flac, both from wav and aiff and both formats are showing the same speed decrease when using 1.3.0. To give an idea of the speed decrease, encoding at flac level 8: 24/96 wav file 1.21: 61.05 seconds. ratio=0.690 1.3: 222.48

a. Intel 2.8 Ghz Core I7 (dual core, I7-4558U) in late 2013 Macbook Pro with Retina Display b. I compiled it the same way I compiled 1.2.1: ./configure -enable-static -disable-shared CFLAGS=" -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6" make Am i doing something wrong? Thanks, Scott On Fri, Jul 25, 2014 at 12:54 PM, lvqcl <lvqcl.mail at gmail.com>

I will post to the dev list, sorry about that. To give an idea, though, at flac level 8: 24/96 wav file 1.21: 61.05 seconds. ratio=0.690 1.3: 222.48 seconds. ratio=0.690 smaller 16/44.1 wav file 1.21: 14.28 seconds. ratio=0.487 1.3: 51.21 seconds. ratio=0.487 Scott On Fri, Jul 25, 2014 at 2:39 AM, <dathead2 at gmail.com> wrote: > Are you sure they didn't change the default

Why are you using such an old SDK? Your Macbook came with at least Mountain Lion, right? I have a Retina Macbook mid 2012, and it came with ML... On Fri, Jul 25, 2014 at 3:00 PM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit >

Miroslav Lichvar wrote: > Well, this reverts the commit 18e0154. How is the user supposed to set > CFLAGS without getting -O3 -funroll-loops there? (e.g. to minimize the > size of the compiled binaries) Is it -O3 or -funroll-loops that you have a problem with? Or both? What would you prefer to see as the default optimisation level? I'm sure there is a solution to this. Lets find

ERROR while decoding data state = FLAC__STREAM_DECODER_END_OF_STREAM It's happening with every file that I've tried now, using both 1.2.1 and 1.3.0. If a file has artwork and I remove padding, I get the above error when verifying or decompressing. If no artwork and I remove padding, the file verifies and decompresses with no issues. I'm writing tags via

hi, according to the FAQ flac supports multichannel formats. i had no luck with 1.1.4 though ( "Untitled.aif: ERROR: unsupported number channels 8 for AIFF" ), i guess that feature was added in 1.2? unfortunately, the binary for 1.2 does not run on OS X 10.4 (says libiconv is too old). i removed libiconv and reinstalled that from source, but then flac 1.2.1 just prints

The patch I submitted only reads AIFF files. I'm about to start the patch to write AIFF files. To do so, we need a command-line option to specify AIFF. My inclination is to add an option: -ff { raw | wav | aif } In some sense, "-ff" is silly since it probably stands for "format format". Still, I think it's better than just "-f", since the first

Martijn van Beurden wrote: > op 25-07-14 19:32, Scott Brown schreef: > > ./configure -enable-static -disable-shared CFLAGS=" -isysroot > > /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6" > > make > > Well, the use of CFLAGS 'disables' the -O3 and unroll-loops > optimisation. I'm quite sure that's the culprit. Add -O3 to your

I know this is probably blindingly obvious, but I can't find it anywhere. Is there a way to tell the Vorbis codec what endian your samples are or do I have to do my own byte reversal. AIFF is Be's 'standard' audio file format, and its encoded big endian, not little endian even on Intel boxes. I know for decoding ov_read has an endian option, but I can't see an equaivalent for

lvqcl wrote: > I just built FLAC and noticed that the size of flac.exe is noticeably bigger, > so I compared the generated Makefiles before ang after this change. > > The difference is: "-g -O2" options were added to CFLAGS. > > before: > CFLAGS = -O3 -funroll-loops -Wall -W -Winline -Wall -Wextra -Wstrict-prototypes > -Wmissing-prototypes -Waggregate-return

Hi, I am attempting to use flac to encode 96k/24-bit broadcast wav (BWF) files. BWFs are wav files with some extra meta-data chunks, and is the favoured archival format for many institutions around the world. These files are encoded successfully by flac, however the resulting flac file is not playable on all flac players - it plays successfully in foobar2000 but is silent in winamp, and when

yes that is what i did. got the "requires version 7.0.0 or later, but libiconv.2.dylib provides version XYZ" (forgot which version i had before). removed libiconv, downloaded compiled and installed the new one (libiconv-1.13.1), then i just get $ flac Bus error i reinstalled flac 1.1.4, still runs fine (but doesn't support multichannel). cheers, -sciss- Am 05.08.2009 um

Hello, in fact : this error(FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DAT) occurs when the sample size is bigger than the exepected size in the encoder. Now, can someone tell me how to model the signal, for example : *using a Fixed linear predictor for the input signal ? * 2012/4/13 Brian Willoughby <brianw at sounds.wa.com> > > On Apr 12, 2012, at 07:12, Rafael Velasquez

flac.exe is choking on some aiff files as input with the following: "ERROR: SSND chunk size inconsistent with sample frame count" According to Daren on the dBpoweramp forum "The flac.exe program ignores the amount of data bytes quoted in the SSND chunk and tries to read to the end of the file, which would be fine if the SSND data was the last data in the file. The problem is

just recently I have finished implementing support for saving non-audio chunks in RIFF WAVE and AIFF with the FLAC file in application metadata blocks, and restoring them when decoding. you can read about more about it here: http://www.hydrogenaudio.org/forums/index.php?showtopic=56968 the zip file there has windows binaries; CVS HEAD has everything checked in if you need a different platform.

On Tue, Jul 29, 2014 at 07:47:33PM +1000, Erik de Castro Lopo wrote: > Miroslav Lichvar wrote: > > > Well, this reverts the commit 18e0154. How is the user supposed to set > > CFLAGS without getting -O3 -funroll-loops there? (e.g. to minimize the > > size of the compiled binaries) > > Is it -O3 or -funroll-loops that you have a problem with? Or both? > What would

Not sure if this belongs here or in flac-dev. I am subscribed to both, so flop it over if fits better over there. Looking at the Changelog for FLAC 1.2.1 (17-Sep-2007), it says: "With the new --keep-foreign-metadata in flac, non-audio RIFF and AIFF chunks can be stored in FLAC files and recreated when decoding." Where can I find more detail on what is a