Skip to main content

Topic: FLAC 1.2.0 released (Read 59991 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • benski
  • [*][*][*][*][*]
  • Developer
FLAC 1.2.0 released
Reply #50
How can you use the new libFLAC.dll with CDex? I use CDex version 1.70b2 unicode version, and with new libFLAC.dll it crashes, just as it did with libFLAC.dll 1.1.4.
Any suggestions?


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.

  • AngelGR
  • [*][*][*][*]
FLAC 1.2.0 released
Reply #51
Thanks very much John. 
I'll keep using the external encoder option until they fix it.

  • Kluyg
  • [*]
FLAC 1.2.0 released
Reply #52
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?
  • Last Edit: 27 July, 2007, 03:39:05 PM by Kluyg

  • xmixahlx
  • [*][*][*][*][*]
FLAC 1.2.0 released
Reply #53
i'm missing the part where you can't do that yourself for some reason.

  • Saoshyant
  • [*][*]
FLAC 1.2.0 released
Reply #54
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.
Join //spreadopenmedia.org to promote Vorbis, FLAC, Speex, etc

  • goodnews
  • [*][*][*]
  • Banned
FLAC 1.2.0 released
Reply #55
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:
Ogg FLAC file extension is now .oga and the MIME type audio/ogg.
FLAC on native encapsulation format will remain .flac and application/flac.
  • Last Edit: 28 July, 2007, 04:07:19 AM by goodnews

  • Egor
  • [*][*][*][*][*]
FLAC 1.2.0 released
Reply #56
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.)

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

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.

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.

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[...]

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

  • Synthetic Soul
  • [*][*][*][*][*]
  • Global Moderator
FLAC 1.2.0 released
Reply #57
Wow, two new versions of lossless codecs released within half a day.

That calls for an updated comparison chart...
Tell me about it.

I'm hoping to run my tests this weekend, when I know the PC will be free.
New figures are there.  FLAC 1.2.0 is approximately 8% faster encoding and decoding than 1.1.4.
I'm on a horse.

  • goodnews
  • [*][*][*]
  • Banned
FLAC 1.2.0 released
Reply #58
Thanks for all the great info Egor! I greatly appreciate it. It answered my questions about this new FLAC 1.2.0 version.
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.
  • Last Edit: 28 July, 2007, 06:29:26 AM by goodnews

  • jcoalson
  • [*][*][*][*][*]
  • Developer
FLAC 1.2.0 released
Reply #59
I don't suppose there's been any communication with Apple to ensure the FLAC support they will (apparently) be shipping with Leopard has the necessary support for this. It'd be a shame for them to ship something that had just become outdated. Particularly as they seem to 'lose focus' on a lot of projects, so any future updates are hardly guaranteed.
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.

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.
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.

  • goodnews
  • [*][*][*]
  • Banned
FLAC 1.2.0 released
Reply #60
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

  • DOS386
  • [*][*]
FLAC 1.2.0 released
Reply #61
> 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 ?
/\/\/\/\/\/\

  • jamesbaud
  • [*][*][*]
FLAC 1.2.0 released
Reply #62
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 interested in the answer to Kluyg's question too. John33? (I have an AMD Athlon 64 X2 Dual Core Processor 4600+ 2.4 Ghz).

  • Egor
  • [*][*][*][*][*]
FLAC 1.2.0 released
Reply #63
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:
The Intel compile may be slightly faster, but there will be no difference at all with regard to the quality. I only post the MSVC compiles as some people feel more comfortable with them. I may get around to compiling a P4 specific Intel version, but that will be of no use to you.

  • Kluyg
  • [*]
FLAC 1.2.0 released
Reply #64
Egor Thanx

  • goodnews
  • [*][*][*]
  • Banned
FLAC 1.2.0 released
Reply #65
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!

  • ffooky
  • [*][*][*][*]
FLAC 1.2.0 released
Reply #66
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.

  • jcoalson
  • [*][*][*][*][*]
  • Developer
FLAC 1.2.0 released
Reply #67
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...
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

  • Synthetic Soul
  • [*][*][*][*][*]
  • Global Moderator
FLAC 1.2.0 released
Reply #68
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.
I'm on a horse.

  • probedb
  • [*][*][*][*][*]
FLAC 1.2.0 released
Reply #69
Excellent  Now I'd best dig out that script someone posted to run through and reconvert all my FLAC files from 1.1.4.....
no need this time, compression will be the same.


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

  • gharris999
  • [*][*]
FLAC 1.2.0 released
Reply #70
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.

  • jcoalson
  • [*][*][*][*][*]
  • Developer
FLAC 1.2.0 released
Reply #71
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.

  • tebasuna51
  • [*][*]
FLAC 1.2.0 released
Reply #72
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.

  • jcoalson
  • [*][*][*][*][*]
  • Developer
FLAC 1.2.0 released
Reply #73
hmm, can you make a small version of the problem wave files and host or upload them?

  • tebasuna51
  • [*][*]
FLAC 1.2.0 released
Reply #74
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