FLAC 1.2.1 is out, the major addition being support for all RIFF/AIFF metadata, including Broadcast Wave Format (BWF) via the new --keep-foreign-metadata (http://flac.sourceforge.net/documentation_tools_flac.html#flac_options_keep_foreign_metadata) option. There are many other small improvements and bug fixes; see the changelog entry (http://flac.sourceforge.net/changelog.html#flac_1_2_1) for complete details.
Thanks Josh! I hope a Universal Mac version is due out soon
FLAC becomes better and better - compression rate and speed is growing, additional RIFF/AIFF metadata can be stored. For de'facto standard lossless codec (at least in open source world) it is great.
Good work, Josh, thank you very much.
BTW, it's time to update wiki page of "Lossless comparison" and remove 'unable to support RIFF chunks' from cons.
Thanks Josh! I hope a Universal Mac version is due out soon
Me too! Thanks for all your hard work Josh!
Is the new option --keep-foreign-metadata recommended for files generated by EAC? I think it is only needed for WAV files with metainformation such as timestamp points etc used by Wavelab and other Sound-Editting apps.
Great work! For my purposes FLAC really is the most complete lossless codec available, thanks jcoalsen.
(a really minor gripe though: could the windows installer please ask me if I would like to have a desktop icon?)
Is the new option --keep-foreign-metadata recommended for files generated by EAC?
No, it isn't.
Thanks for the great work Josh!
However, I am not too sure what SF# 1764105 (https://sourceforge.net/tracker/index.php?func=detail&aid=1764105&group_id=13478&atid=113478) - "Fixed bug where importing non-CDDA cuesheets would cause an invalid lead-out track number" means. Can someone please tell me what this means in plain English?
Also, is this a serious enough bug to warrant a trancode of all my FLAC images from v1.1.4 to v1.2.1? I am totally confused
Read this post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=56128&view=findpost&p=506876). Previously, when embedding a cue sheet in a flac file that was created from non-CD audio, the lead-out track number would be incorrect. Starting with this new version of FLAC, the lead-out track number for non-CD audio will always be 255.
You don't have to transcode anything unless you have such files. In other words, if your FLAC images are CD-DA rips (44.1 kHz, 16 bit, stereo), you're fine.
Thanks Josh! I hope a Universal Mac version is due out soon
Universal binary ready for download at my website...
Enjoy!
I wasn't sure what your URL for downloads of the Mac version was, but just found it in your profile:
http://homepage.mac.com/krmathis/ (http://homepage.mac.com/krmathis/)
Thanks! Downloaded it...
just got a report that if you use "flac --replay-gain" but no padding option, the resulting file will have a very small padding block. I'll upload a new installer soon, or the workaround is to use a -P option with your preferred amount of padding.
uploaded new installer with --replay-gain fix here:
http://downloads.sourceforge.net/flac/flac-1.2.1b.exe (http://downloads.sourceforge.net/flac/flac-1.2.1b.exe)
Thanks for the new version.
Seems the problems reading WAVE_FORMAT_EXTENSIBLE headers by STDIN, repported in this post (http://www.hydrogenaudio.org/forums/index.php?showtopic=56386&st=50#), are solved.
Josh. Is this a fix at source code level or part of the MS Windows installer package only?
Meaning, will we see a new source code tarball?
By the way. I appreciate the work you put into this.
Thanks!
Josh. Is this a fix at source code level or part of the MS Windows installer package only?
Meaning, will we see a new source code tarball?
haven't decided on that yet, full releases are quite a pain. if other urgent bugs pop up I might. in the meantime you can pick up all urgent fixes to 1.2.1 via the maintenance branch, i.e. check out by branch tag FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH
Josh. Is this a fix at source code level or part of the MS Windows installer package only?
Meaning, will we see a new source code tarball?
haven't decided on that yet, full releases are quite a pain. if other urgent bugs pop up I might. in the meantime you can pick up all urgent fixes to 1.2.1 via the maintenance branch, i.e. check out by branch tag FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH
Josh, these releases might "be a pain", but having several 1.2.1 versions with different code branches and possible problems should not be allowed. I recommend you make the fixes 1.2.2 and not 1.2.1 branch. People need to rely on a version, and having bugs causes people to be leery to use that version I believe. Just my opinion.
haven't decided on that yet, full releases are quite a pain. if other urgent bugs pop up I might. in the meantime you can pick up all urgent fixes to 1.2.1 via the maintenance branch, i.e. check out by branch tag FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH
I see..
WIll check out the maintenance branch, and follow closely in case you decide to put out a 1.2.1b tarball.
in the meantime you can pick up all urgent fixes to 1.2.1 via the maintenance branch, i.e. check out by branch tag FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH
Now padding with replaygaining works well, thank you.
--keep-foreign-metadata seems to be fine:
046335deef981b35f3227f0315cc9bc8 *file.wav
046335deef981b35f3227f0315cc9bc8 *file_decoded.wav
a. should i expect any problems?
b. what exactly is the latest cmd version? (i have extracted one from installer flac-1.2.1b.exe, is that the latest?)
tnx
a. should i expect any problems?
b. what exactly is the latest cmd version? (i have extracted one from installer flac-1.2.1b.exe, is that the latest?)
a. This release is considered to be stable, so expect no problems
b. Yes, the one from the installer is the latest. By the way, the only difference is a really small fix (use of the --replay-gain option caused no padding).
egor, tnx, the problems with '--keep-foreign-metadata' is the question?
Thank you, Josh
FLAC 1.2.1 is out, the major addition being support for all RIFF/AIFF metadata, including Broadcast Wave Format (BWF) via the new --keep-foreign-metadata (http://flac.sourceforge.net/documentation_tools_flac.html#flac_options_keep_foreign_metadata) option. There are many other small improvements and bug fixes; see the changelog entry (http://flac.sourceforge.net/changelog.html#flac_1_2_1) for complete details.
Not only thanks for your work on FLAC, this is also a textbook example of a good news post. I would like to see more news submissions like that from other people; brief and to the point.
and remove 'unable to support RIFF chunks' from cons.
Done.
"RIFF/AIFF metadata, including Broadcast Wave Format (BWF) via the new --keep-foreign-metadata"
So can I use FLAC to compress wav files used in multitrack projects in programs like SONAR, Cubase, Pro Tools etc and maintain the time position data and stuff like that? This would be really great
"RIFF/AIFF metadata, including Broadcast Wave Format (BWF) via the new --keep-foreign-metadata"
So can I use FLAC to compress wav files used in multitrack projects in programs like SONAR, Cubase, Pro Tools etc and maintain the time position data and stuff like that? This would be really great
should work if they are valid wave files. wave64 (sound forge) does not work yet though.
--keep-foreign-metadata seems to be fine:
046335deef981b35f3227f0315cc9bc8 *file.wav
046335deef981b35f3227f0315cc9bc8 *file_decoded.wav
a. should i expect any problems?
it has been beta tested but it is also a new feature, that's why the --delete-input-file option has been disabled when --keep-foreign-metadata is used. it's a good idea to compare like this for a while until you're satisfied it is working for you.
Josh, these releases might "be a pain", but having several 1.2.1 versions with different code branches and possible problems should not be allowed. I recommend you make the fixes 1.2.2 and not 1.2.1 branch. People need to rely on a version, and having bugs causes people to be leery to use that version I believe. Just my opinion.
I would say to treat anything that says flac 1.2.1 as having that bug. I fixed the windows installer because it's quick and is the most widely used version, so that most of the people who don't know about the bug won't get bit.
The new Winamp plugin doesn't play Ogg FLAC files.
I have tried it with the ogg and the oga extension.
'--keep-foreign-metadata' is really exciting news. This feature opens the door to the world of sample libraries where for example loop points needs to be stored. I won't be surprised to find support for flac in future versions of Native Instruments Kontakt, for example.
This way, musicians may benefit from flac where loading times of huge libraries will decrease significantly!
uploaded new installer with --replay-gain fix here:
http://downloads.sourceforge.net/flac/flac-1.2.1b.exe (http://downloads.sourceforge.net/flac/flac-1.2.1b.exe)
Is the zipped download updated as well?
VUPlayer 2.49, AudioTester 1.4, and FLAC Adobe Audition Filter all updated by James Chapman for FLAC 1.2.1. support.
Download web page links below for each FLAC 1.2.1 supporting program/utility:
VUPlayer: http://www.vuplayer.com/vuplayer.php (http://www.vuplayer.com/vuplayer.php)
AudioTester: http://www.vuplayer.com/other.php (http://www.vuplayer.com/other.php)
Audition FLAC File Filter: http://www.vuplayer.com/audition.php (http://www.vuplayer.com/audition.php)
uploaded new installer with --replay-gain fix here:
http://downloads.sourceforge.net/flac/flac-1.2.1b.exe (http://downloads.sourceforge.net/flac/flac-1.2.1b.exe)
Is the zipped download updated as well?
unfortunately no.
uploaded new installer with --replay-gain fix here:
http://downloads.sourceforge.net/flac/flac-1.2.1b.exe (http://downloads.sourceforge.net/flac/flac-1.2.1b.exe)
Is the zipped download updated as well?
unfortunately no.
my temporary mirror of zipped latest (hopefully) version:
http://somestuff.org/downloads/flac121b/ (http://somestuff.org/downloads/flac121b/)
Thanks for all your great work Josh. Flac is where it's at!
Running the Windows installer under Parallels on a MacBook, Flac frontend seems to fail to install. Installation wizard gives the error:
"there was an error registering a needed file with the operating system: flac frontend may not run."
and on attempting to run flac frontend, I get the error:
"Component 'MSCOMTL.OCX' or one of its dependencies not correctly registered: a file is missing or invalid."
I presume this is a problem with Parallels (build 3214), but thought I should report it.
My other question is regarding the universal binaries posted by krmathis: Where should I place these so that mac programs that use flac such as xact or cog, will find them and use the newer version?
Thanks again!
I know this was mentioned before, but it would be great to have the Nero Flac plugin included in the downloads. The proper installation is to copy the plugin to the C:\Program Files\Common Files\Ahead\AudioPlugins folder. It would really be grand if the plugin could be included in the zip download. It's a pain having to run the installer just for the nero plugin.
Or you could just provide a link to afterdawns neroplugin site:
http://neroplugins.afterdawn.com/ (http://neroplugins.afterdawn.com/)
I know this was mentioned before, but it would be great to have the Nero Flac plugin included in the downloads. The proper installation is to copy the plugin to the C:\Program Files\Common Files\Ahead\AudioPlugins folder. It would really be grand if the plugin could be included in the zip download. It's a pain having to run the installer just for the nero plugin.
To best of my knowledge, the Nero FLAC 3rd party plugin hasn't been updated since FLAC 1.1.0 (August 6, 2003), and I reported a bug in loading or saving mono FLAC 44.1khz 16 bit files, but it was never fixed. I can't trust that 3rd party Nero plugin. Would be nice if the Nero developers would include native FLAC read and write support in Nero...
My other question is regarding the universal binaries posted by krmathis: Where should I place these so that mac programs that use flac such as xact or cog, will find them and use the newer version?
Let me see...
* xACT are self contained. Just replace the FLAC binary inside the .app and you are all set.
* Cog use the FLAC framework, and not the command line binary.
I know this was mentioned before, but it would be great to have the Nero Flac plugin included in the downloads. The proper installation is to copy the plugin to the C:\Program Files\Common Files\Ahead\AudioPlugins folder. It would really be grand if the plugin could be included in the zip download. It's a pain having to run the installer just for the nero plugin.
To best of my knowledge, the Nero FLAC 3rd party plugin hasn't been updated since FLAC 1.1.0 (August 6, 2003), and I reported a bug in loading or saving mono FLAC 44.1khz 16 bit files, but it was never fixed. I can't trust that 3rd party Nero plugin. Would be nice if the Nero developers would include native FLAC read and write support in Nero...
I agree that FLAC should be supported natively by NERO. I wonder if the bloated Nero 8 does so.
Let me see...
* xACT are self contained. Just replace the FLAC binary inside the .app and you are all set.
* Cog use the FLAC framework, and not the command line binary.
Thanks.
If I understand, this means I have to wait for a future version of Cog that uses the new framework?
What about slimserver, (which is what I most use to listen to flacs)?
And is there any point in transcoding from flacs encoded in 1.1.3 or 1.1.4? Would I gain much space? I have about 1.3 TB of flacs.
Somebody with the connections/authority/"ability to code" might want to get on the ffmpeg guys' cases. At least with ffmpeg 0.4.9_p20070616-r1 from Gentoo Portage, playing of 1.2.1 flacs appears to be broken. (Using ffplay actually segfaults.) Thankfully, xine-lib, audacious, and mpd all use libFLAC, but mplayer uses ffmpeg's flac decoder. And it was me just going to preview a 1.2.1 encoded flac with mplayer that I noticed the problem.
Thanks.
If I understand, this means I have to wait for a future version of Cog that uses the new framework?
Yes. Either that or compiling the FLAC framework yourself, for use in Cog
Thanks Josh,
Another mingw32 compile note: make fails due to this conditional at the top of \include\share\alloc.h, which prevents stdint.h from being #included, leaving SIZE_MAX undefined.
#if !defined _MSC_VER &&!defined __MINGW32__ && !defined __EMX__
#include <stdint.h> /* for SIZE_MAX in case limits.h didn't get it */
#endif
-Bahman
IMPORTANT NOTE:some people have had problems with 24bit files encoded with flac-1.2.1. what is happening is that the encoder is taking advantage of 1.2.x features to encode the 24bit file more efficiently. this was not supposed to be released yet to give s/w more time to update to a 1.2.x decoder, but was picked up by a CVS merge that was too broad. specifically, the files are using RICE2 partitions (http://flac.sourceforge.net/format.html#partitioned_rice2). 1.2.x decoders handle this fine so you can get back the original using a 1.2.x decoder if this is causing a problem.
the change to the decoder needed to support RICE2 partitions is pretty trivial; I will try and get in touch with ffmpeg about it.
Josh
I know this was mentioned before, but it would be great to have the Nero Flac plugin included in the downloads. The proper installation is to copy the plugin to the C:\Program Files\Common Files\Ahead\AudioPlugins folder. It would really be grand if the plugin could be included in the zip download. It's a pain having to run the installer just for the nero plugin.
Or you could just provide a link to afterdawns neroplugin site:
http://neroplugins.afterdawn.com/ (http://neroplugins.afterdawn.com/)
I'm a little bit hesitant to include a shaky plugin but now that you've described the procedure it's at least possible for me to do it! thanks.
And is there any point in transcoding from flacs encoded in 1.1.3 or 1.1.4? Would I gain much space? I have about 1.3 TB of flacs.
there was a compression improvement in 1.1.4, otherwise, no. see the FLAC changelog (http://flac.sourceforge.net/changelog.html)
Another mingw32 compile note: make fails due to this conditional at the top of \include\share\alloc.h, which prevents stdint.h from being #included, leaving SIZE_MAX undefined.
#if !defined _MSC_VER &&!defined __MINGW32__ && !defined __EMX__
#include <stdint.h> /* for SIZE_MAX in case limits.h didn't get it */
#endif
thanks, fixed in CVS.
Somebody with the connections/authority/"ability to code" might want to get on the ffmpeg guys' cases. At least with ffmpeg 0.4.9_p20070616-r1 from Gentoo Portage, playing of 1.2.1 flacs appears to be broken. (Using ffplay actually segfaults.) Thankfully, xine-lib, audacious, and mpd all use libFLAC, but mplayer uses ffmpeg's flac decoder. And it was me just going to preview a 1.2.1 encoded flac with mplayer that I noticed the problem.
is this happening on a 24bps stream? that's the only thing I can think of. if so, read the previous important note. if not, can you host or upload a small flac file that causes a crash?
Josh
FLAC becomes better and better - compression rate and speed is growing, additional RIFF/AIFF metadata can be stored. For de'facto standard lossless codec (at least in open source world) it is great.
Good work, Josh, thank you very much.
BTW, it's time to update wiki page of "Lossless comparison" and remove 'unable to support RIFF chunks' from cons.
Whoa are you serious there? Should I re-encode all of my CDS with the new version then? I just finished encoding all of my CDs with the last version of FLAC!
Somebody with the connections/authority/"ability to code" might want to get on the ffmpeg guys' cases. At least with ffmpeg 0.4.9_p20070616-r1 from Gentoo Portage, playing of 1.2.1 flacs appears to be broken. (Using ffplay actually segfaults.) Thankfully, xine-lib, audacious, and mpd all use libFLAC, but mplayer uses ffmpeg's flac decoder. And it was me just going to preview a 1.2.1 encoded flac with mplayer that I noticed the problem.
is this happening on a 24bps stream? that's the only thing I can think of. if so, read the previous important note. if not, can you host or upload a small flac file that causes a crash?
Josh
Hmm, well, I did a quick test, and it appears that ffmpeg chokes on my flacs that have the album art in the tags. (Added using "metaflac --import-picture-from=cover.jpg") Removing the album art and resulting padding block fixes the problem.
BTW, it's time to update wiki page of "Lossless comparison" and remove 'unable to support RIFF chunks' from cons.
Whoa are you serious there? Should I re-encode all of my CDS with the new version then? I just finished encoding all of my CDs with the last version of FLAC!
not necessary, ripped WAVs are not affected.
Hmm, well, I did a quick test, and it appears that ffmpeg chokes on my flacs that have the album art in the tags. (Added using "metaflac --import-picture-from=cover.jpg") Removing the album art and resulting padding block fixes the problem.
I checked out the ffmpeg source, it looks like they use a 64k buffer to try and read in all the metadata and the first FLAC frame. so if you've got a big jpeg in there that method will fail. that should be fixed.
I did manage to make a 3 line patch though to fix the 1.2.x stuff which I'll be submitting shortly.
Josh
In the Partitioned Rice 2 (http://flac.sourceforge.net/format.html#partitioned_rice2) documentation, I've noticed the "Encoding Parameter" section reads "0000-11110 : Rice parameter." when it should probably read "00000-11110 : Rice parameter." in order to cover the full five bits. I'm sure that's just a cut & paste typo, but I thought I'd mention it just the same.
@jcoalson:
Is the Rice2 coding method only in use for 24 bit files?
Is the Rice2 coding method only in use for 24 bit files?
currently it's only enabled if the input is more than 16bps, and 24bps is the only resolution >16 that the command-line encoder supports right now, so yes. it will probably stay that way since it's extremely unlikely to be utilized in 16bps audio anyway.
Josh
Has 1.2.1's 24-bit problem been fixed yet? Foobar2k won't play 24-bit flac files I made with 1.2.1 downloaded from flac.sourceforge.net last week...
Any news about a new version with the --replay-gain fix (1.2.2, or...)?
Meaning not just the 1.2.1b binary for MS Windows, but an updated source tarbal for use on any OS as well.
Has 1.2.1's 24-bit problem been fixed yet? Foobar2k won't play 24-bit flac files I made with 1.2.1 downloaded from flac.sourceforge.net last week...
I guess there are two ways to fix that:
Either a command-line switch for FLAC to disable the use of Rice2 codes or updating the FLAC libaries of fb2k to version 1.2.x
I haven't decided whether or not to remove the 1.2.x 24bit improvement from 1.2.2. I don't want to add a switch since that affects the API. the improvement is significant for some files and other software/devices already support it (including the squeezebox).
the --replay-gain + (no padding) fix will be in 1.2.2 which is probably a month away.
updating the FLAC libaries of fb2k to version 1.2.x
Since FLAC decoding is a part of foo_input_std, you can't update it.
Put your update requests [a href='index.php?showtopic=57774']here[/a] and hope that Peter will have time and motivation.
Has 1.2.1's 24-bit problem been fixed yet? Foobar2k won't play 24-bit flac files I made with 1.2.1 downloaded from flac.sourceforge.net last week...
I guess there are two ways to fix that:
Either a command-line switch for FLAC to disable the use of Rice2 codes or updating the FLAC libaries of fb2k to version 1.2.x
I fixed it a third way:
decoded the files with 1.2.1, re-encoded with 1.1.4
Put your update requests [a href='index.php?showtopic=57774']here[/a] and hope that Peter will have time and motivation.
FLAC 1.2.1 support is already in the internal 0.9.5 builds so it's only a matter of getting 0.9.5 out the door.
FLAC 1.2.1 support is already in the internal 0.9.5 builds so it's only a matter of getting 0.9.5 out the door.
Wow! That's a joyous news! Many thanks.
the --replay-gain + (no padding) fix will be in 1.2.2 which is probably a month away.
Thanks! That answered my question.
Has 1.2.1's 24-bit problem been fixed yet? Foobar2k won't play 24-bit flac files I made with 1.2.1 downloaded from flac.sourceforge.net last week...
I guess there are two ways to fix that:
Either a command-line switch for FLAC to disable the use of Rice2 codes or updating the FLAC libaries of fb2k to version 1.2.x
I fixed it a third way:
decoded the files with 1.2.1, re-encoded with 1.1.4
even easier, just do flac->flac with 1.2.0
[quote name='naturfreak' post='520312'
I fixed it a third way:
decoded the files with 1.2.1, re-encoded with 1.1.4
even easier, just do flac->flac with 1.2.0
I had 1.1.4 handy, but not 1.2.0
FLAC 1.2.1 support is already in the internal 0.9.5 builds ...
foobar2000 0.9.
4.5 is just released .. is 0.9.5 next?
i'm pretty sure the "in_flac.dll" that comes with 1.2.1b has a bug where in winamp it bypasses the EQ. it still responds to the pre-amp in the EQ, but not the band sliders. or if it does it is VERY dull, and hardly noticeable.
i didn't upgrade winamp yet, still using an old 5.35 the only thing i've changed was the "in_flac.dll" file from my flac upgrade. running xp if it means anything.
anyone else can recreate? should i post this in a winamp thread too or not due to cross posting?
edit - i just rolled back to the "in_flac.dll" that comes bundled with winamp 5.35, all fixed.
Which is the LASTEST FLAC version:
1.2.1a or 1.2.1b???
Thanks ahead of time to all of you for your help
Which is the LASTEST FLAC version:
1.2.1a or 1.2.1b???
Thanks ahead of time to all of you for your help
1.2.1b
OK what's the deal here with FLAC and NERO8? I just installed the Frontend but it didn't install the dll for Nero. So does Nero 8 work with FLAC or not? If so, how does one go about running FLAC in Nero to create CDROMs from an FLAC file?
CLIPPED to UPDATE:
So anyway, is there a way to get FLAC to CD working with Nero 8?
Use Foobar. It works perfectly! It creates CDs from FLAC files, or you can convert the FLAC to WAV and use NEro, etc.
I just wanted to post this update so others who are wondering might see it.
You represent about 1/10 of 1 millionth of a percent.
I would suspect that more than 6.6 people use FLAC......
btw, Nero is not the only package that you can use to create CD's from FLAC files.
You represent about 1/10 of 1 millionth of a percent.
I would suspect that more than 6.6 people use FLAC......
btw, Nero is not the only package that you can use to create CD's from FLAC files.
6.6 poeple--lol.
Well, I installed Foobar and the burring plug in, since I have Nero 8 installed. it's burning right now .
I would not mind using another program to burn FLAC to CD besides Nero. I only use NEro to burn data and Music CDs anyway,m so I don't need ANYTHING it offers besides burning data and music, and less and less music CDs because I use an SD card for my car stereo and home stereo now.
Anyway, for what it is worth for those looking:
As stated in this thread, if you are wanting to burn FLAC to CD, and you have nero installed, install Foobar 2000, and then on the Foobar site, look for the "additional Componenets link:
http://www.foobar2000.org/components/index.html (http://www.foobar2000.org/components/index.html)
Then look for the component called: CD burning support and follow it's instructions to install in.
After you do that, start Foobar and open all the FLAC files you want to burn to a CD. Then, right click on the FLAC files and you will see a context menu item called "Burn CD." That's it. Very nice.
So anyway, what other program can I sue to burn FLAC to CD?
Thanks again!
--END OF POST, REPLIES BELOW:
Well, for some reason, a mod decided I should be suspended from posting until Dec 26th, but I have no idea why. Please let me reply here to the responses below:
imre_herceq
"The problem is that most software people are using for burning audio CDs do not wish to offer you all possible choices, they want to promote one or other format (WMP - wma, iTunes - ALAC and AAC, Nero - AAC). So your opinion of using wav is not entirely pointless."
Thanks. Yes, wav file is universally supported, although it's much bigger than the FLAC. I guess the board mods think differently than you do about the post.
---
Probbedb
"So did you actually want to ask a question or did you just want to come and insult all the FLAC users on here?"
Now this is what I would call a troll post, since the questions are clearly started in my post.
The questions are in the first paragraph of the post and the last sentence of the post. They end in question marks.
I didn't realize that commenting on the usability of FLAC for the general music enthusiast was insulting FLAC uses--of which I am one. I will continue to use FLAC EAC/REAC 2 because I like it and I admire the progress in this field. and it works for me. The post was simply pointing out that there is another way to rip and store files that is more universally accepted, and for most people, will result in easier conversion back to CDs, not to mention that your average computer simi literate person will never figure out EAC/REACT2 Foobar for FLAC, AAC, MP3 ripping and converting back to CD.
---
fbuser
"That is definitely wrong. The saving is about 40% for pop music and about 50% for classical music."
You're right. But I didn't say that wav files are only 15% bigger than FLAC files. I said, "The time spent trying to decode FLAC to CD is not worth the 10-15% space you will save over simply ripping to wav--which is universally supported by all software--and then squishing the wavs with RAR."
But this is wrong, really. If you can figure out that you need a different program, like Foobar, and then the Plugin that uses Nero, and you have Nero installed, it's very easy. But finding and cobbling these components--or others that will convert FLAC to CD-- will take most people some time.
---
Mr Bungle
"I'm not going to quote dwd but I must say that was a top quality troll. Good enough to get me to login to HA whilst on holidays, just to reply. Thanks for the laugh!"
As you can see by my replies, this is no troll post. I'm serious about what I have had to say here.
It has in it real and valid arguments about the usability of FLAC as compared to wav files regarding usability of FLAC and the general public. My problem with FLAC isn't with FLAC, since it simply is a great compression algorithm for music files--the best. My problem with FLAC is its implementation only.
I mean look at what a person would have to know and understand simply to use EAC/REACT to do specific things--they have to understand ini files and DOS cfg files for starters, and that is a very tall order to ask of people who have other things to do besides spend hours learning computer oriented scripting and so on.
That said, for sure the developers of the scripts and programs to help FLAC use, that being mainly Foobar, EAC, and REACT are commendable indeed. This is no flame, troll, or other undesirable post. It is simply saying that ease of use is the biggest problem I see with this entire project, and unless we all want it to stay as a sort of cult type audio compression converting club, then there has to be some way, for lack of better words, of tying together the usability of CD Ripping to FLAC --> AAC -->MP3 --> then FLAC --> CD again. Do you disagree with that?
----
Also, I'm sorry that I could not respond in kind, but again, the board mod has scene fit to suspend my posting privilege for "trolling and being an asshat." I guess it's for what I consider valid points I made above about the useability of FLAC to CD etc.
I really think suspending me for this post is childish--one of the mods even said "Enjoy your stay on HA while it last." Yeah that's cute. You have the power, so suspend people who you disagree with, even though they contribute useful information.
If taken seriously, it could have been a useful information link for those wanting information on FLAC to CD. Plus I posted a direct link to the FLAC/Foobar burning plugin that uses Nero calls, and took the time to explain how to use it/install it for those not as knowledgeable as most of you.
I'll probably get banned for sticking up for myself like this, but it's worth it to me. I don't like to be abused for trolling when I'm dead serious about this. It's not fair and I feel like it is an abuse of power. I was simply looking for information and at the same time sharing my frustrations with the project, and taking the time to explain to others how to use Foobar/Nero/FLAC to CD.
You can use Burrrn (http://www.burrrn.net/?page_id=4), and for data CD-R/W and DVD±R/W/DL burning I suggest ImgBurn (http://www.imgburn.com/), both freeware and way less bloated'n Nero 7 or 8.
The time spent trying to decode FLAC to CD is not worth the 10-15% space you will save over simply ripping to wav--which is universally supported by all software--and then squishing the wavs with RAR.
Well, I am listening mostly to classical music where the Flac file is generally about 40-50% of the wav size. (I know that compression ratios with pop-rock music are different.)
Besides I use Linux and burn audio CDs with K3b. So using Flac is a valid choice for me. Indeed, I haven't burned an audio CD from wav for some time.
I know, however, that only few people burn classical music CDs, and few people use Linux.
The problem is that most software people are using for burning audio CDs do not wish to offer you all possible choices, they want to promote one or other format (WMP - wma, iTunes - ALAC and AAC, Nero - AAC). So your opinion of using wav is not entirely pointless.
OK what's the deal here with FLAC and NERO8? I just installed the Frontend but it didn't install the dll for Nero. So does Nero 8 work with FLAC or not? If so, how does one go about running FLAC in Nero to create CDROMs from an FLAC file?
FLAC is great technology, but it's not supported smoothly enough to be a major player in CD to FLAC to CD conversions yet. I would suggest for most people to simply rip to wav file and use RAR to compress them. Sure, you'll save about another 10-15% using FLAC, but then you'll spend all your time trying in vain to convert FLAC to CDs without first converting them from FLAC to WAV.
The time spent trying to decode FLAC to CD is not worth the 10-15% space you will save over simply ripping to wav--which is universally supported by all software--and then squishing the wavs with RAR. Not only that, but FLAC continues to develop, so if you want the best archive copy you'll need to once again spend hours ripping to FLAC format. Well, forget compressing the wavs with RAR because a 750GB drive is not about 130.00 US. So who cares?
I seriously suggest, after doing all of this myself, to convert using WAV files, compress usign RAR, and then sitting on the wavs until FLAC is much better supported by plugins or natively and developed so you don't end up re FLACing your entire collection a year later. I would say FLAC will surpass WAV files for archiving CDs in about 3-5 more years.
I know people will disagree, but consider yourselves to be elite users of cutting edge converting software. You represent about 1/10 of 1 millionth of a percent. The general computer literate CD ripping person doesn't even know what FLAC is, much less how to use it. They do know what a WAV is and how to rip to wav and create CDs and MP3s from wavs, simply because wav -mps -aac - and wav to CD is supported well. Flac is not.
So anyway, is there a way to get FLAC to CD working with Nero 8?
So did you actually want to ask a question or did you just want to come and insult all the FLAC users on here?
The time spent trying to decode FLAC to CD is not worth the 10-15% space you will save over simply ripping to wav
That is definitely wrong. The saving is about 40% for pop music and about 50% for classical music.
I'm not going to quote dwd but I must say that was a top quality troll. Good enough to get me to login to HA whilst on holidays, just to reply.
Thanks for the laugh!
FLAC 1.2.1 support is already in the internal 0.9.5 builds so it's only a matter of getting 0.9.5 out the door.
mmh, foobar2000 v0.9.5.1 doesn't playback 24 bit flac files properly here! foobar basically can read the file, but the output gets distorted!
here an example: http://www.outburst-audio.com/misc/24-bps.flac (http://www.outburst-audio.com/misc/24-bps.flac) (1.2 MB)
FIXED (or at least a workaround got added in Foobar2000 0.9.5.2)
Reaper (http://www.reaper.fm) for example plays it fine!
deleted (turned out to be a foobar issue)
No problem here, with FLAC 1.2.1 and a 24bit/96kHz stereo file.
flac -t says the file is OK, and I can play it back fine.
What I found was that Foobar 9.4 wouldn't play the FLAC 1.2.1 file correctly -- it would cut off after some interval (different for different tracks). THis is not the distortion problem noted for v9.5; I haven't heard that.
But Winamp plays the same file completely, with no audible issues.
Using FLAC 1.1.4 instead allowed foobar 9.4 to play the files through with no problem.
So, I concluded that f2K 9.4 has a problem with 24-bit files compressed with Flac 1.2.1.
No problem here, with FLAC 1.2.1 and a 24bit/96kHz stereo file.
flac -t says the file is OK, and I can play it back fine.
vs.
What I found was that Foobar 9.4 wouldn't play the FLAC 1.2.1 file correctly -- it would cut off after some interval (different for different tracks). THis is not the distortion problem noted for v9.5; I haven't heard that.
But Winamp plays the same file completely, with no audible issues.
Using FLAC 1.1.4 instead allowed foobar 9.4 to play the files through with no problem.
So, I concluded that f2K 9.4 has a problem with 24-bit files compressed with Flac 1.2.1.
If i remember right, FLAC 1.2.x has introduced new rice codes to more efficiently code big residuals. Earlier decoders most probably can't decode files using those codes.
If those codes are beeing used depends on the size of the residuals and this size may depend on bit depth, amplitude and predictability of the signal to compress.
The residuals for 24bit/96kHz are often quite small, therefore it's possible that the new codes have not been used in skamp's file. -> No compatibilty problems.
krabapple' file may contain some parts with big residuals where the encoder has deceided to use the new bit codes. Old decoders can playback until the first passage containing those new incompatible codes.
Just my 2 cents.
Thomas
the --replay-gain + (no padding) fix will be in 1.2.2 which is probably a month away.
I was just curious when version 1.2.2 might be released?
Obviously, the timetable here must have changed. Just wondering, thanks.
Yeah, I was kind of wondering that myself...
sorry, such is the way for some open-source projects. I've been swamped at my day job since then and some new things have been added (recently checked in support for rf64 and wave64, and native win64 builds, needed by key customers). when I get enough time for a release I will put it out but can't say when it will be now.