FLAC 1.2.0 is out. There are a few new features and some speedups and fixes, but more importantly, there are some small changes to the decoder to pave the way for possible future compression improvements, so applications developers are encouraged to upgrade (the API has not changed). The changelog (http://flac.sourceforge.net/changelog.html#flac_1_2_0) has all the details, but in summary:
- automatic SSE OS detection at runtime (so no need to specifically enable SSE at compile time)
- small encoder and decoder speedups
- new --ignore-chunk-sizes option in flac will help with fb2k piped encoding to flac.exe
Awesome! Thanks!
You are a gentleman and a scholar.
*tests*
FLAC 1.2.0 is out.
Thank you Josh.
Then Foobar2000 and Cooledit plugin need to update.
- new --ignore-chunk-sizes option in flac will help with fb2k piped encoding to flac.exe
do you mean that the problem about reaching the maximum seek points in the file is gone?
Thank you Josh.
Then Foobar2000 and Cooledit plugin need to update.
um why?
- new --ignore-chunk-sizes option in flac will help with fb2k piped encoding to flac.exe
do you mean that the problem about reaching the maximum seek points in the file is gone?
Yes, though you will need to manually update the parameters string for converter (make a custom preset) and tell fb2k developers it would be great to change the FLAC preset on occasion.
Thank you Josh !
Thank you Josh.
Then Foobar2000 and Cooledit plugin need to update.
um why?
Exactly... why? I assume backwards compatibility should not be a problem at this time at least since the decoder was updated for
future possible compression improvements.
v1.2.0 "--ignore-chunk-sizes" seems to not create any seek point. Is it safe for decoder compatibility?
metaflac --list sample1.flac (encoded with
%s -o %d)
METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 14 bytes
maximum framesize: 14295 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 21142128
MD5 signature: dc7707fe44e414873c67e3597ef44079
METADATA block #1
type: 3 (SEEKTABLE)
is last: false
length: 864
seek points: 48
point 0: sample_number=0, stream_offset=0, frame_samples=4096
point 1: sample_number=438272, stream_offset=863109, frame_samples=4096
point 2: sample_number=880640, stream_offset=1703274, frame_samples=4096
point 3: sample_number=1318912, stream_offset=2421506, frame_samples=4096
point 4: sample_number=1761280, stream_offset=3205408, frame_samples=4096
point 5: sample_number=2203648, stream_offset=4013462, frame_samples=4096
point 6: sample_number=2641920, stream_offset=4752195, frame_samples=4096
point 7: sample_number=3084288, stream_offset=5562112, frame_samples=4096
point 8: sample_number=3526656, stream_offset=6396950, frame_samples=4096
point 9: sample_number=3964928, stream_offset=7311730, frame_samples=4096
point 10: sample_number=4407296, stream_offset=8213471, frame_samples=4096
point 11: sample_number=4849664, stream_offset=9124752, frame_samples=4096
point 12: sample_number=5287936, stream_offset=10007487, frame_samples=4096
point 13: sample_number=5730304, stream_offset=10973161, frame_samples=4096
point 14: sample_number=6172672, stream_offset=11975115, frame_samples=4096
point 15: sample_number=6610944, stream_offset=13090217, frame_samples=4096
point 16: sample_number=7053312, stream_offset=14139121, frame_samples=4096
point 17: sample_number=7495680, stream_offset=15086376, frame_samples=4096
point 18: sample_number=7933952, stream_offset=15992142, frame_samples=4096
point 19: sample_number=8376320, stream_offset=17001045, frame_samples=4096
point 20: sample_number=8818688, stream_offset=17969089, frame_samples=4096
point 21: sample_number=9256960, stream_offset=18727284, frame_samples=4096
point 22: sample_number=9699328, stream_offset=19690182, frame_samples=4096
point 23: sample_number=10141696, stream_offset=20527314, frame_samples=4096
point 24: sample_number=10579968, stream_offset=21274576, frame_samples=4096
point 25: sample_number=11022336, stream_offset=22153031, frame_samples=4096
point 26: sample_number=11464704, stream_offset=23198098, frame_samples=4096
point 27: sample_number=11902976, stream_offset=24314989, frame_samples=4096
point 28: sample_number=12345344, stream_offset=25441145, frame_samples=4096
point 29: sample_number=12787712, stream_offset=26470938, frame_samples=4096
point 30: sample_number=13225984, stream_offset=27428645, frame_samples=4096
point 31: sample_number=13668352, stream_offset=28361327, frame_samples=4096
point 32: sample_number=14110720, stream_offset=29440696, frame_samples=4096
point 33: sample_number=14548992, stream_offset=30516648, frame_samples=4096
point 34: sample_number=14991360, stream_offset=31584719, frame_samples=4096
point 35: sample_number=15433728, stream_offset=32745588, frame_samples=4096
point 36: sample_number=15872000, stream_offset=33527464, frame_samples=4096
point 37: sample_number=16314368, stream_offset=34214583, frame_samples=4096
point 38: sample_number=16756736, stream_offset=34933179, frame_samples=4096
point 39: sample_number=17195008, stream_offset=35779963, frame_samples=4096
point 40: sample_number=17637376, stream_offset=36868855, frame_samples=4096
point 41: sample_number=18079744, stream_offset=38032471, frame_samples=4096
point 42: sample_number=18518016, stream_offset=38939203, frame_samples=4096
point 43: sample_number=18960384, stream_offset=39979350, frame_samples=4096
point 44: sample_number=19402752, stream_offset=41156540, frame_samples=4096
point 45: sample_number=19841024, stream_offset=42423269, frame_samples=4096
point 46: sample_number=20283392, stream_offset=43668945, frame_samples=4096
point 47: sample_number=20725760, stream_offset=44939333, frame_samples=4096
METADATA block #2
type: 4 (VORBIS_COMMENT)
is last: false
length: 40
vendor string: reference libFLAC 1.2.0 20070715
comments: 0
METADATA block #3
type: 1 (PADDING)
is last: true
length: 8192
metaflac --list sample2.flac (encoded with
- -o %d)
METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 14 bytes
maximum framesize: 14295 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 21142128
MD5 signature: dc7707fe44e414873c67e3597ef44079
METADATA block #1
type: 3 (SEEKTABLE)
is last: false
length: 21924
seek points: 1218
point 0: sample_number=0, stream_offset=0, frame_samples=4096
point 1: sample_number=438272, stream_offset=863109, frame_samples=4096
point 2: sample_number=880640, stream_offset=1703274, frame_samples=4096
point 3: sample_number=1318912, stream_offset=2421506, frame_samples=4096
point 4: sample_number=1761280, stream_offset=3205408, frame_samples=4096
point 5: sample_number=2203648, stream_offset=4013462, frame_samples=4096
point 6: sample_number=2641920, stream_offset=4752195, frame_samples=4096
~
~
~
point 1212: sample_number=534492000, stream_offset=0, frame_samples=0
point 1213: sample_number=534933000, stream_offset=0, frame_samples=0
point 1214: sample_number=535374000, stream_offset=0, frame_samples=0
point 1215: sample_number=535815000, stream_offset=0, frame_samples=0
point 1216: sample_number=536256000, stream_offset=0, frame_samples=0
point 1217: sample_number=536697000, stream_offset=0, frame_samples=0
METADATA block #2
type: 4 (VORBIS_COMMENT)
is last: false
length: 40
vendor string: reference libFLAC 1.2.0 20070715
comments: 0
METADATA block #3
type: 1 (PADDING)
is last: true
length: 65536
metaflac --list sample3.flac (encoded with
--ignore-chunk-sizes - -o %d)
METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 14 bytes
maximum framesize: 14295 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 21142128
MD5 signature: dc7707fe44e414873c67e3597ef44079
METADATA block #1
type: 4 (VORBIS_COMMENT)
is last: false
length: 40
vendor string: reference libFLAC 1.2.0 20070715
comments: 0
METADATA block #2
type: 1 (PADDING)
is last: true
length: 8192
And I found the last FLAC takes more CPU cycle to seek with long flac files (55 minutes - 400MB).
v1.2.0 seems to not create any seek point. Is it safe for decoder compatibility?
metaflac --list sample1.flac (encoded with %s -o %d)
METADATA block #1
type: 3 (SEEKTABLE)
is last: false
length: 864
seek points: 48
point 0: sample_number=0, stream_offset=0, frame_samples=4096
point 1: sample_number=438272, stream_offset=863109, frame_samples=4096
point 2: sample_number=880640, stream_offset=1703274, frame_samples=4096
point 3: sample_number=1318912, stream_offset=2421506, frame_samples=4096
I don't understand - what are those, if not seekpoints?
I don't understand - what are those, if not seekpoints?
FLAC - documentation
http://flac.sourceforge.net/documentation_...t_overview.html (http://flac.sourceforge.net/documentation_format_overview.html)
Other blocks allow for padding, seek tables, tags, cuesheets, and application-specific data. There are flac options for adding PADDING blocks or specifying seek points. FLAC does not require seek points for seeking but they can speed up seeks, or be used for cueing in editing applications.
My question also is solved. >Is it safe for decoder compatibility?
FLAC - documentation
http://flac.sourceforge.net/documentation_...t_overview.html (http://flac.sourceforge.net/documentation_format_overview.html)
I still don't understand what you meant. I have read the format documentation many times, and as far as I know, those are seekpoints... Am I so tired that I am missing something?
FLAC - documentation
http://flac.sourceforge.net/documentation_...t_overview.html (http://flac.sourceforge.net/documentation_format_overview.html)
I still don't understand what you meant. I have read the format documentation many times, and as far as I know, those are seekpoints... Am I so tired that I am missing something?
Sorry, I made mistake. What I meant was:
v1.2.0
"--ignore-chunk-sizes" seems to not create any seek point.
Great Josh
Thanks! I upgraded . Also, good work on getting an executable installer out at the same time too .
Wow, two new versions of lossless codecs released within half a day.
That calls for an updated comparison chart...
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.
seekpoints are not required but can improve seek times. with --ignore-chunk-sizes, a seektable is currently not added. in the future I plan to have the encoder go back and add one after encoding is finished and it knows the total number of samples. a workaround in the meantime is to add a seektable afterwards with metaflac.
Exactly... why? I assume backwards compatibility should not be a problem at this time at least since the decoder was updated for future possible compression improvements.
a 1.2.0 decoder will be able to decode any 1.2.x streams, so upgrading now means not having to when 1.2.x encoder improvements come out. the FLAC 1.1.x series spanned 4.5 years.
Thanks! I upgraded . Also, good work on getting an executable installer out at the same time too .
yes, this should be the norm now that I have my own nsi script.
Wow, two new versions of lossless codecs released within half a day.
That calls for an updated comparison chart...
speaking of which, FLAC and WavPack encode at the same speed by default but have different ratings on the wiki (http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison).
Thanks for the new version! I'm just wondering: why that version numbering jump (1.1.x -> 1.2.x) ?
Thanks for the new version! I'm just wondering: why that version numbering jump (1.1.x -> 1.2.x) ?
that's teh unix system (MAJOR).(MINOR).(REVISION)
it usually points to compatibility issue(s)
later
Great, however, every time I try to download the Windows version, I get a file with size 0. Has anyone successfully downloaded the 1.2.0 Windows version?
<3
Great, however, every time I try to download the Windows version, I get a file with size 0. Has anyone successfully downloaded the 1.2.0 Windows version?
There's a compile on Rarewares as well, if that's easier.
Josh,
Thank you for the new release!!!
Any chance of the RAW CD TOC support in upcoming revisions?
Great, however, every time I try to download the Windows version, I get a file with size 0. Has anyone successfully downloaded the 1.2.0 Windows version?
looks like a problem with one of the mirrors, I fixed the download link on download.html
Any chance of the RAW CD TOC support in upcoming revisions?
it's on the TODO, can't assign a chance just yet but it's non-zero!
I cannot download from any sourceforge mirror. I am getting a file not found 404 message for the Windows installer.
Can you please fix.
Thanks
I don't know what the problem is with sourceforge, I think they might be checking the referrer now or something, try copy-pasting this link into the address bar, it just worked for me:
http://downloads.sourceforge.net/flac/flac-1.2.0a.exe (http://downloads.sourceforge.net/flac/flac-1.2.0a.exe)
if not, download it via the sourceforge file section: http://sourceforge.net/project/showfiles.p...lease_id=527434 (http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=12675&release_id=527434)
I have tried that, but all mirrors are coming up with a 404 error.
Thanks
I have tried that, but all mirrors are coming up with a 404 error.
Thanks
I was able to download via the mirror "superb-east.dl.sourceforge.net ( McLean, Virginia - North America )"
Try that one.
Nope, still dead.
Are you able to email me the exe file?
scott at aceblue.com
Thanks
I've given up on posting the links. Just try different mirrors, cancel on the popup and instead right-click on the direct link and choose save link as...
THANKS JOSH!!!
Can't seem to be able to download anything from Sourceforge at this point!
zip worked, exe still dead...
I have tried with my a diffrent net connection, and the exe will not work there as well.
Thanks greynol.
Exactly... why? I assume backwards compatibility should not be a problem at this time at least since the decoder was updated for future possible compression improvements.
a 1.2.0 decoder will be able to decode any 1.2.x streams, so upgrading now means not having to when 1.2.x encoder improvements come out. the FLAC 1.1.x series spanned 4.5 years.
While I do see the point in upgrading the decoders since it will become necessary to do so in the future once the upgrades kick in I assume it will be some time before any improvements will kick in to allow for developers to update their software and hardware manufacturers to update firmwares to support 1.2.0
Hence I mostly meant it as that it doesn't necessarily have to be done
right now, since it sounded as if it was necessary for 1.2.0 to be useful, but I do see the point for it eventually.
Thanks for your hard work, Josh!
While I do see the point in upgrading the decoders since it will become necessary to do so in the future once the upgrades kick in I assume it will be some time before any improvements will kick in to allow for developers to update their software and hardware manufacturers to update firmwares to support 1.2.0
actually I've been working with hardware people since Jan (because it takes longer for firmware to propagate). at this point it's more the software apps but these are easier to upgrade especially since the API hasn't changed.
Excellent Now I'd best dig out that script someone posted to run through and reconvert all my FLAC files from 1.1.4.....
Flac 1.2.0 vs 1.1.4 on a Prescott 2.8ghz UNDERCLOCKED to 1.85ghz.
Ratio is related to my so called SetF.
Average improvement: 20/25% in encoding speed, 5/10% in decoding speed.
Mode Ratio Enc(1.1.4)Dec Enc(1.2.0)Dec
|| -0 || 70,03 || 41,7x | 50,5x || 47,9x | 54,3x ||
|| -1 || 68,24 || 39,8x | 46,8x || 45,0x | 51,4x ||
|| -2 || 68,09 || 33,6x | 48,5x || 38,0x | 52,4x ||
|| -3 || 66,35 || 31,6x | 46,1x || 41,4x | 48,7x ||
|| -4 || 64,15 || 24,1x | 44,5x || 34,1x | 47,4x ||
|| -5 || 64,00 || 19,1x | 44,5x || 26,1x | 48,5x ||
|| -6 || 64,00 || 18,6x | 44,4x || 25,1x | 48,0x ||
|| -7 || 63,91 || 8,3x | 44,6x || 10,1x | 48,4x ||
|| -8 || 63,65 || 6,0x | 44,3x || 7,0x | 47,4x ||
Great work Josh!
While I do see the point in upgrading the decoders since it will become necessary to do so in the future once the upgrades kick in I assume it will be some time before any improvements will kick in to allow for developers to update their software and hardware manufacturers to update firmwares to support 1.2.0
actually I've been working with hardware people since Jan (because it takes longer for firmware to propagate). at this point it's more the software apps but these are easier to upgrade especially since the API hasn't changed.
Oh, that's cool, then I guess we might see more improvement in flac in the near future than I expected. Nice work Josh.
Flac 1.2.0 vs 1.1.4 on a Prescott 2.8ghz UNDERCLOCKED to 1.85ghz.
Ratio is related to my so called SetF.
Average improvement: 20/25% in encoding speed, 5/10% in decoding speed.
Mode Ratio Enc(1.1.4)Dec Enc(1.2.0)Dec
|| -0 || 70,03 || 41,7x | 50,5x || 47,9x | 54,3x ||
|| -1 || 68,24 || 39,8x | 46,8x || 45,0x | 51,4x ||
|| -2 || 68,09 || 33,6x | 48,5x || 38,0x | 52,4x ||
|| -3 || 66,35 || 31,6x | 46,1x || 41,4x | 48,7x ||
|| -4 || 64,15 || 24,1x | 44,5x || 34,1x | 47,4x ||
|| -5 || 64,00 || 19,1x | 44,5x || 26,1x | 48,5x ||
|| -6 || 64,00 || 18,6x | 44,4x || 25,1x | 48,0x ||
|| -7 || 63,91 || 8,3x | 44,6x || 10,1x | 48,4x ||
|| -8 || 63,65 || 6,0x | 44,3x || 7,0x | 47,4x ||
which compile did you use? thanx.
Flac 1.2.0 vs 1.1.4 on a Prescott 2.8ghz UNDERCLOCKED to 1.85ghz.
which compile did you use? thanx.
This (http://downloads.sourceforge.net/flac/flac-1.2.0-win.zip?modtime=1185296423&big_mirror=0) one.
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.
FLAC 1.2.0 is out. There are a few new features and some speedups and fixes, but more importantly, there are some small changes to the decoder to pave the way for possible future compression improvements
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.
YES. Compressed with 1.1.4 and 1.2.0 and result files were identical except version and date string.
I cannot download from any sourceforge mirror.
No download problems for me.
I wonder whether in future there is a chance for source simplifications or a separate minimal UN-FLAC - couldn't find any so far ... and the full source package is not really tiny or simple ...
While I do see the point in upgrading the decoders since it will become necessary to do so in the future once the upgrades kick in I assume it will be some time before any improvements will kick in to allow for developers to update their software and hardware manufacturers to update firmwares to support 1.2.0
actually I've been working with hardware people since Jan (because it takes longer for firmware to propagate). at this point it's more the software apps but these are easier to upgrade especially since the API hasn't changed.
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.
Is there an updated libFLAC.dll for CDex?
Is there an updated libFLAC.dll for CDex?
I've just added the dlls to the 'Lossless' page at Rarewares.
Edit: So they're available for when the API has been sorted in CDex!!
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?
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.
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) (http://www.rarewares.org/files/lossless/flac-1.2.0.zip) or ICL9.1 compile (557kB) (http://www.rarewares.org/files/lossless/flac-1.2.0-icl.zip)? 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 (http://wiki.xiph.org/index.php/MIME_Types_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:
Ogg FLAC file extension is now .oga and the MIME type audio/ogg.
FLAC on native encapsulation format will remain .flac and application/flac.
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.
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.
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.
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 (http://wiki.xiph.org/index.php/MIME_Types_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.
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 (http://www.hydrogenaudio.org/forums/index.php?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 ?
Can anyone tell me please which compile is better: MSVC8 Compile (433kB) (http://www.rarewares.org/files/lossless/flac-1.2.0.zip) or ICL9.1 compile (557kB) (http://www.rarewares.org/files/lossless/flac-1.2.0-icl.zip)? 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).
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.
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!
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 (http://tmkk.hp.infoseek.co.jp/xld/index_e.html) has been updated to 1.2.0.
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 (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 (http://www.synthetic-soul.co.uk/comparison/lossless/?all=1).
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.
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.
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?
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 (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/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 (https://sourceforge.net/tracker/index.php?func=detail&aid=1776803&group_id=13478&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
ok, this may be related to this bug:
https://sourceforge.net/tracker/index.php?f...amp;atid=113478 (https://sourceforge.net/tracker/index.php?func=detail&aid=1776803&group_id=13478&atid=113478)
for some reason on some/all version of windows, fseek()ing forward on stdin fails. all these examples work fine on *nix.
Yes, seems a problem with Windows. With Vista also fails.
will fix for the next release.
Thanks.
ok, this may be related to this bug:
https://sourceforge.net/tracker/index.php?f...amp;atid=113478 (https://sourceforge.net/tracker/index.php?func=detail&aid=1776803&group_id=13478&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, 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.