$ gcc -vReading specs from c:/mingw/bin/../lib/gcc/mingw32/3.4.2/specsConfigured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debugThread model: win32gcc version 3.4.2 (mingw-special)
Flake r100 mingw-buildSame location as last time.Building was quite smooth, but I didn't use the makefile (don't know if I even could, I'm quite new to this). I just started CodeBlocks, added all needed files for the library to a project, set the compiler paths so it could find bswap.h and added an empty config.h. Setting up the project for flake was almost the same.There was only one warning when building:flake\wav.c:473: warning: enumeration value 'WAV_SAMPLE_FMT_UNKNOWN' not handled in switchThat was already present with the gcc 3 I used before (can't remember the exact version)
I haven't been able to compile using MinGW since rev 48. If I run ./configure I get:/bin/cat: /tmp/flake-conf-10500-6548-17128.c: No such file or directorygcc is unable to create an executable file.It still works with cygwin.I don't need to compile, but I thought it worth pointing out, as it seems relevant at the moment.
Does flake use autotools? If yes, would a ./autogen.sh generate new ./configure* files?
edit: looks like I was too slow. I'm glad it works for you now.
I just downloaded Rev. 19 of configure and that works fine. Rev. 50 (the next version) does not.
Hmm. Are you not using ./configure + make because it doesn't work? If you have msys installed that's all that you should need to do.
I had the same problem. Get this: http://optusnet.dl.sourceforge.net/sourcef...napshot.tar.bz2 and put the binaries in your msys\1.0\bin directory.
Quote from: Justin Ruggles on 03 October, 2006, 09:30:37 AMHmm. Are you not using ./configure + make because it doesn't work? If you have msys installed that's all that you should need to do.I didn't install msys, no. I have never used it yet. I know ./configure -scripts from building Linux apps, but I never wrote one or used one under Windows. Hmm, if I have no problems compiling Flake without running ./configure first, does CodeBlocks do the necessary stuff that ./configure normally does?As I said, I'm quite new to this.
you have #include <inttypes.h> at wav.h . just though i should point that out. just tried building it again with VC++ 2005 and it blew up on syntax errors. i'll try to rebuild it in the future with VC++ 2005 when i get interested in doing that again.
Flake: FLAC audio encoder© 2006 Justin Rugglesusage: flake [options] <input.wav> [output.flac]
Flake: FLAC audio encoder© 2006 Justin Rugglesusage: flake [options] <input.wav> [-o output.flac]options: [-h] Print out list of commandline options [-p #] Padding bytes to put in header (default: 4096)...
The compile Garf offered a while back works flawlessly on the Squeezebox and has higher compression already as standard 1.1.2.
Ah, oh. I see a problem. Does -12 take that much processing power or isn´t it 100% compatible to flac 1.1.2 decoding anymore?My Squeezebox can´t play flake -12 on all titles. It stutters around. Flake -5 for example is fine.
Quote from: Wombat on 05 October, 2006, 11:50:46 AMThe compile Garf offered a while back works flawlessly on the Squeezebox and has higher compression already as standard 1.1.2.That has more similarities with the upcoming FLAC 1.1.3, or FLAC 1.1.2_CVS from this thread.
After Bukem's positive report, your one is the first negative one and is precisely what I feared.My own decoding tests done with foobar2000 and my old Duron revealed that -11 and -12 are considerably slower than all other modes and than official/Garf's encoder. From memory, it's ~x48 for flake high profile and a bit more than x60 for all other settings/encoders.As a consequence I expected from some devices with few 'power' headroom to have troubles decoding -q11/12 encodings.Could you also try with -q10 and -q11? I guess that the first one should be problem free and the latter to sutter as well as -q12.