That's because the API changed in 1.1.4. The CDex author will need to update the code to use the new FLAC API.

Thanks very much John.
I'll keep using the external encoder option until they fix it.

Can anyone tell me please which compile is better: MSVC8 Compile (433kB) or ICL9.1 compile (557kB)? Or there is no difference? I mean in speed (I have Intel Core 2 Duo E6420 CPU).
Edit: ups, what quality I was talking about when discussing lossless?

i'm missing the part where you can't do that yourself for some reason.

There's also a change on FLAC, which isn't based on new version but came out at the same time. Developers may be interested to know that Ogg FLAC file extension is now .oga and the MIME type audio/ogg. FLAC on native encapsulation format will remain .flac and application/flac. This is per the MIME Type and File Extensions proposal, which has now become an official Xiph policy.

To clear up compatability questions about this new FLAC 1.2.0 version:

1. Are FLAC 1.1.x encoded files going to play OK with all FLAC 1.2.x decoders (1.2.0 and later) to ensure compatability? (i.e. they will never need to be re-encoded, right?, as the older encoded files won't ever stop playing in new FLAC decoders.)

2. Are FLAC 1.2.x files going to to play OK in FLAC 1.1.x decoders OK? Will a FLAC 1.2.0 encoded file play OK (without a decoder update) in an app using a FLAC 1.1.2, 1.1.3, or 1.1.4 decoder.

Just wanted to clear up these 2 questions regarding compatability, as I plan on releasing FLAC files of my music masters for people to use/enjoy on the Net. I need to know if I should distribute masters encoded with 1.1.4, or if I should upgrade them to FLAC 1.2.0 for maximum future (and present) compatability, as I know there will be app makers that may never upgrade their FLAC decoders (some still are using 1.1.2)?

Also thanks for the MIME Type and File Extensions clarification:

Yes, all future FLAC decoders will surely decode 1.1.x.


1.2.0 files will play OK in 1.0.x and 1.1.x software. Though future 1.2.x releases (e.g. 1.2.1) may require at least 1.2.0 decoder, so developers are encouraged to update decoders to 1.2.0 now.


You don't need to upgrade your 1.1.4 files, they will be compatible with present and future decoders.

New figures are there. FLAC 1.2.0 is approximately 8% faster encoding and decoding than 1.1.4.

Thanks for all the great info Egor! I greatly appreciate it. It answered my questions about this new FLAC 1.2.0 version.

I sure would like to talk to them, but I think with maybe just one exception, no one at apple has ever even replied to any of my emails, including conversations they themselves started. I don't know anyone there but if someone else can hook me up, PM me.

yep, missed this for 1.2.0 but it will be the default in 1.2.1. until then the name can be overriddend with -o

Egor answered the compatibility thing pretty well; one more thing to add is that I don't plan on releasing encoder changes that older decoders can't play until the 1.2.x decoder has propagated out enough to not be a problem for users. this may take a while.

James Chapman just released his updated FLAC filter for Adobe Audution and his updated AudioTester app, both now with FLAC 1.2.0 support. He also updated the Ogg Vorbis support to 1.2.0 as well.

http://www.hydrogenaudio.org/forums/index....showtopic=56462

> You don't need to upgrade your 1.1.4 files, they will be compatible with present and future decoders.

In fact 1.2.0 files (all ?) are byte identical with 1.1.4 ones except date and version string.

> until the 1.2.x decoder has propagated out enough

What about a simpler (decoder) source ?

I'm interested in the answer to Kluyg's question too. John33? (I have an AMD Athlon 64 X2 Dual Core Processor 4600+ 2.4 Ghz).

The answer from another topic:

Egor Thanx

Josh,

Any success on releasing an Intel Mac OS X compile of FLAC 1.2.0?

Surely, someone out there knows how to compile it for Mac OS X 10.4...

Thanks!

While we're waiting for that, the latest build of XLD has been updated to 1.2.0.

not yet, I don't have a machine but Brian Willoughby might have one soon.

P.S. I revamped the comparison page, now results are sortable by column, and for both encoding and decoding there are 2 time columns, one for total process time and one for just cpu time (no I/O).

http://flac.sourceforge.net/comparison.html

This seems a suitable time and place to mention that, following some advice from Josh, I ran some tests on my corpus using FLAC 1.2.0 encoding with no MD5 sum.

The results are not part of my core data, as I'm still currently of the opinion that 'default' settings should be compared, but they (and some others) can be viewed by appending ?all=1 to the URL.

I have to say, the increase in speed is impressive. I was confused by the associated increase in decompression speed, but Josh has confirmed that is to be expected.

Ahh ok, thanks for the info on this Saved me a job.

Josh: thanks for adding the --no-utf8-convert option to FLAC. I'm finding that a straight MSVC2005 compile of your latest CVS code, using your selected compiler optimizations, really can't be improved upon. I've tried all kinds of other compiler optimizations and also tried the ICL9 Intel compiler. None of the other compiles that I tried were faster on my hardware. Congrats, and thank you.

that's kind of a relief, after messing with it so much! another interesting thing I found was that the build using old MSVC6 was a little faster still at decoding, but a little slower encoding, at least on the machines I tested with, so that's the one I ended up distributing. but maybe on some newer machines the VS2005 one might be a little better overall.

Seems Flac 1.2.0 (also 1.1.3 and 1.1.4) have problems reading WAVE_FORMAT_EXTENSIBLE header by STDIN.

I'm using W XP sp1 and this work:

flac stereo_standar_or_exten.wav
flac multichan_exten.wav
type stereo_standar.wav | flac - -o output.flac

I know these new versions need WAVE_FORMAT_EXTENSIBLE for multichannel:

flac multichan_standard.wav
ERROR: WAVE has >2 channels but is not WAVE_FORMAT_EXTENSIBLE; cannot assign channels

But with:

type stereo_or_multichan_exten.wav | flac - -o output.flac

I get:

WARNING: skipping unknown sub-chunk ' '
WARNING: skipping unknown sub-chunk ' '
...
ERROR during read while skipping unsupported sub-chunk

Also work:

type multichan_standard.wav | flac - -o output.flac --channel-map=none

Then the problem is only with WAVE_FORMAT_EXTENSIBLE header by STDIN.

hmm, can you make a small version of the problem wave files and host or upload them?

The problem is for all WAVE_FORMAT_EXTENSIBLE headers, not for ones in particular.

With the samples in http://www-mmsp.ece.mcgill.ca/Documents/Au...VE/Samples.html
we can see than work:

flac M1F1-int16-AFsp.wav -o stereo_standard.flac
flac M1F1-int16WE-AFsp.wav -o stereo_extensible.flac
flac 6_Channel_ID.wav -o multichan_extensible.flac
type M1F1-int16-AFsp.wav | flac - -o stereo_standard.flac

And don't work:

type M1F1-int16WE-AFsp.wav | flac - -o stereo_extensible.flac
type 6_Channel_ID.wav | flac - -o multichan_extensible.flac

These wav's have some extrachunks well detected in direct mode, but using the most simple WAVE_FORMAT_EXTENSIBLE header the problem is the same:

-: WARNING: skipping unknown sub-chunk ' '
...
-: WARNING: skipping unknown sub-chunk 'Ï Eú'
-: ERROR during read while skipping unsupported sub-chunk

ok, this may be related to this bug:
https://sourceforge.net/tracker/index.php?f...amp;atid=113478
for some reason on some/all version of windows, fseek()ing forward on stdin fails. all these examples work fine on *nix. will fix for the next release.

Josh

Yes, seems a problem with Windows. With Vista also fails.



Thanks.

Yes, we had to work around this problem too. If the input file is not a regular file but a pipe, then we just read in those bytes, instead of seeking forward. It's a bit slower, but seems to work.