From January 2012 FLAC is being maintained by Erik de Castro Lopo under the auspices of the Xiph.org Foundation.
Taken from
https://github.com/crrodriguez/flac (https://github.com/crrodriguez/flac)
...but I guess this guy does not have the access to flac.soureforge.net
From an Email I sent off to Eric,
Mr Spoon wrote:
> We have been trying to find what has happened to Josh for quite a while
He's fine, just not working on FLAC anymore.
> now, we came across https://github.com/crrodriguez/flac (https://github.com/crrodriguez/flac) which suggests =
> you have taken over FLAC management? is this correct?
Yes it is.
> have you taken over flac.sf.net also?
We are in the process of moving the web pages to:
http://xiph.rog/flac/ (http://xiph.org/flac/)
Once that is done, we will ask Josh to set up a HTTP redirect on the
flac.sf.net web site.
Cheers,
Erik
So it seems Josh is no longer working on FLAC, I am concerned that merging into xiph might not be best for FLACs future...(it is nothing personal against xiph), FLAC has a window of opportunity to become the defacto lossless codec, but without strong management it will not (and in 4 years everything will be in Apple lossless, or some such)
I propose that a team from HA is put together and then propose to xiph that such a team take over FLACs stewardship. If you are interested put your name forward, and if the team is strong, we can propose.
Is there a reason to question Eric's stewardship?
FLAC has been under the Xiph umbrella for quite some time. All that is changing is the lead maintainer and the site hosting the FLAC pages and code.
As long as the code remains open for bug fixes and enhancements I don't see a need for people on HA to take over. Those same people are free to work on or promote FLAC without taking control from Xiph.
If it has been under Xiph umbrella for some time, from the outside it seems that FLAC is dead...I propose not more of the same rather something different,
From January 2012 FLAC is being maintained by Erik de Castro Lopo under the auspices of the Xiph.org Foundation.
So it seems Josh is no longer working on FLAC, I am concerned that merging into xiph might not be best for FLACs future...(it is nothing personal against xiph), FLAC has a window of opportunity to become the defacto lossless codec, but without strong management it will not (and in 4 years everything will be in Apple lossless, or some such)
I propose that a team from HA is put together and then propose to xiph that such a team take over FLACs stewardship. If you are interested put your name forward, and if the team is strong, we can propose.
Just as Spoon, I am very concerned that FLAC will miss the opportunity to become the lossless codec standard. I am not an experienced programmer (I am in the progress of transforming from Matlab to Python...)
However, I promise that I will contribute $40 on the first day to fund raise for a free/open source developer team with the 'clear' target to develop FLAC into become the lossless codec standard for any device and OS on the market for free!
I will do/contribute what it takes to avoid an Apple or Microsoft ruled digital audio world (which we are right in the middle of)!
GOOD LUCK my dear FLAC!
xTobix
PS: I am sure there will be more people out there willing to put a few bugs into this since I am certainly not the only person using FLAC as (almost) sole audio container!
PS2: one practical feature I am missing in flac is something like WinRAR offers, a recovery volume creation option with about 3-5%...(don’t if this is patent/license restricted though)
https://github.com/crrodriguez/flac (https://github.com/crrodriguez/flac)
As far as I know, xiph's git with the latest code can be found at http://git.xiph.org/?p=flac.git;a=summary (http://git.xiph.org/?p=flac.git;a=summary).
I am not an experienced programmer (I am in the progress of transforming from Matlab to Python...)
Some experienced programmers already did it (http://numpy.scipy.org/), and they offer some migration tips (http://www.scipy.org/NumPy_for_Matlab_Users).
I am sure there will be more people out there willing to put a few bugs into this
Let's hope not!
Thanks Kohlrabi,
https://github.com/crrodriguez/flac (https://github.com/crrodriguez/flac)
As far as I know, xiph's git with the latest code can be found at http://git.xiph.org/?p=flac.git;a=summary (http://git.xiph.org/?p=flac.git;a=summary).
I am not an experienced programmer (I am in the progress of transforming from Matlab to Python...)
Some experienced programmers already did it (http://numpy.scipy.org/), and they offer some migration tips (http://www.scipy.org/NumPy_for_Matlab_Users).
I am aware of these two sources. In fact I am using EPD Free/EPD Academic from here:
http://www.enthought.com/products/epd_sublevels.php (http://www.enthought.com/products/epd_sublevels.php)
I think this is prity solid to start with and get some experience with it.
@greynol: I understand your concerns - I am just not sure if it will work the other way... we will see
From a code base perspective I'm not sure what else needs to be addressed beyond adding 32-bit support to the reference software, not that 32-bit makes any difference in audio. But, the spec supports it and the reference software should implement what the spec supports. Other than that what else needs to be addressed in the reference implementation?
I think what is really needed is a marketing advocate. Someone willing to spend obscene amounts of time persuading device manufacturers to implement FLAC support in their devices. This is also working on being a moot point since so many media devices being released use Android and starting with 3.1 or so FLAC support is native there.
It would be a nice addition to engage an international standards body to have FLAC ratified as a lossless audio standard (Opus is a great example where Xiph stepped up to the plate on this with the IETF). That would make it much easier to engage manufacturers when you can walk in and ask them to implement a ratified standard instead of a spec some open source foundation supports.
Got it in one yourlord (I think what is really needed is a marketing advocate) - FLAC has battles to fight if it want to become the standard, it will not happen unless it is pushed.
FLAC also needs standards defining in the ID Tags.
I do not see developers being the limiting factor for FLAC.
FLAC needs >2G support
AFAIK the future Xiph's format Ghost will support lossless. But it won't be ready any time soon.
I'm curious as to how you 'push' a audio codec without being a big player, big funding and industry contacts?
It's there, it's free, if people want to use it they can, isn't that the point of free and open software?
Everybody knows somebody...contacts can be found - I wish I had of put more effort in getting FLAC into Windows some 8 years ago, MS were betting on Plays For Sure back then and WMAL so was an uphill battle, even though I had the right contacts. Times have changed, MS no longer have anything, Apple need isolating, so any company which is not Apple needs to convinced to adopt FLAC, they need convincing that it is in their long term interest to do so. Windows once again will be an area of focus.
@greynol: I understand your concerns - I am just not sure if it will work the other way... we will see
greynol was just joking about the irony of your having said “bug”, a problem in software, where you presumably meant
buck, a unit of money.
Strangely the flac development stopped around the same time it became widely supported in hardware mediaplayers like the Squeezebox line.
I wonder if it simply needed to much effort with these already and Mr. Coalson simply felt he spends to much time.
There are several other minor things that come to my mind.
Much flac is sold as hires music while there isn´t even a Replaygain implementation for the higher sampling rates included in metaflac.
Also over time i often did read problems with the way flac integrates into the Windows OS. People have problems with metadata in
Explorer or the standard flac frontend doesn´t work at all.
Over time there also were some efforts to optimize the use of modern resources like a very impressing Open-CL implementation or a multi-threaded built.
It would really be nice to get all these things together somehow and make a simple to use package.
Me as Hydrogen pinhead has no problem to make all these features usable to me but for some average user it is most likely already to annoying.
ALAC is in itunes, needs no additional effort if someone uses it and its TAGs are already recognized in every OS AFAIK.
AFAIK the future Xiph's format Ghost will support lossless. But it won't be ready any time soon.
I'm honestly not really interested in formats that support both lossy and lossless mode. It's purely my opinion, but I like knowing that if I have a FLAC file that I have an exact copy of the audio that was encoded. If I want audio in a form where I don't mind loss, then there are plenty of choices out there. Mixing lossy and lossless audio in the same codec does nothing but confuse the issue and introduce too much chance of mistaking a lossy version as lossless and introducing loss into a signal chain that was intended to be lossless.
Imagine if mp3 had a lossless mode and you had the hordes of noobs out there mangling their encodes because they don't understand the difference. You'd have people loading sansa clips with lossless mp3 files then complaining because they can only get 5 or 6 albums on it. Then you'd have "CD backups" loaded with 128Kbps CBR files. You know it would happen, A LOT.
Keep it simple.
@greynol: I understand your concerns - I am just not sure if it will work the other way... we will see
greynol was just joking about the irony of your having said “bug”, a problem in software, where you presumably meant buck, a unit of money.
thanks for getting me up to speed - I am plagued with dyslexia and even worth my ears are made of flesh and blood, not gold – what the hell... ???
I was also wondering what happened to the FLAC project as a whole, since the official page isn't update in ages. It would be good some pushing forward. (Strangely WavPack is also stuck for quite a while now as well).
(Strangely WavPack is also stuck for quite a while now as well).
So is every other lossless codec, which, alas, includes TAK. I never understood why nobody realized TAK's potential, but take this as a rhetorical question, as to not derail the topic.
More or less, they reached a point of maturity. But they still need to do improvements (2gb limit for example).
It seems impossible to tell what xiph's goals and plans are for FLAC based on what is publically available. Spoon, you've probably thought of this already, but I would not assume that your goals and concerns related to FLAC are shared by xiph without direct discussion, and until such discussion occurs, the speculation could be endless on what they are planning and what we should do. I suggest you call Chris Montgomery or someone else at xiph you know with policy-setting knowledge and influence.
I don't think it's unreasonable for xiph to share quite a bit more on their goals and plans for FLAC, and I would be concerned if and until they do. Certainly any marketing effort, regardless of who does it, will be ineffective at best without such information.
No doubt xiph's funding model might mean FLAC does not develop as fast as users and developers want, but there is no way Apple and other competitors will agree to slow down to accomodate, so some urgency and recognition of a window of opportunity by xiph seems prudent. If you find that some collective expression beyond the few sympathetic posts here is needed to prompt a substantive response from xiph, I'm sure many of us would be glad to add numbers to a more formal request for more information.
Most of this thread is extremely bizarre. Reading it, I have a hard time believing I'm at HA.
FLAC reached maturity years ago. There are few gains to be made on the compression level without breaking compatibility and going for a new format. Nobody has discovered any lossless audio compression technique which can improve on flac's compression level by more than 5%, and everything besides TAK which improves on its compression at all is significantly slower esp. on decode. FLAC has good software and hardware support. What exactly do you guys want?
Complaining about FLAC "merging into xiph" is really bizarre. Xiph is not some sort of shadowy corporation, it's a loose collection of programmers- to some extent, it's whoever shows up to get work done on free codecs. FLAC has been "under the Xiph.Org banner" for almost ten years now.
FLAC is developed in a public repository. It has two active public mailing lists. Development was pretty much stalled for a few years. In the ~9 months since Erik became the primary maintainer it's seen a lot of activity again; take a look at commit messages, etc if you want an idea of the direction development is going. It's mostly build fixes and optimizations for a variety of platforms and compilers. Josh Coalson finally reappeared and has been involved a little bit from time to time too, but he's glad to have Erik filling that role.
Spoon's advocating a hostile takeover of FLAC by some kind of "team from HA" is laughable. People who visit HA are quite welcome to contribute to FLAC if they have the programming mojo to do so. If you want to develop FLAC, you show up with patches, not with ultimatums.
godrick, you say FLAC "doesn't develop as fast as users and developers want, but there is no way Apple and other competitors will agree to slow down to accommodate." The main sign I've seen that FLAC isn't developing "as fast as users want" is that it hasn't become a magical rainbow unicorn format that compresses all of your CD images to one byte each. Apple hasn't done anything of note with ALAC in the eight years since its introduction except for finally opening the source last year. ALAC still- as it has done for eight years- gives marginally worse compression than FLAC while being noticeably slower. I don't think anybody needs to be worried about Apple and some mysterious "other competitors" speeding past FLAC at some tremendous pace of development.
Sure, some kind of major marketing breakthrough would be nice, and in a perfect world MS and Apple would get on board. But that doesn't mean there's any reason to complain about Erik and others.
The technical suggestions people are making are at least better than whining about developers without cause. But some of the suggestions really don't make sense, and for most of the rest, the use cases are obscure enough that it's hard to see why those should be priorities. You're of course welcome to code an improvement yourself, hire somebody to do so, or establish a bounty if a particular obscure use case matters a lot to you.
@Jensend - flac does not hugely need massive development, it has strong open source roots, so what exactly can xiph offer flac now? FLAC needs industry contacts and marketing right now, exactly what xiph is not doing.
Look at the main FLAC page - flac.sf.net it has been dead for 3 years (I am not talking about compiler tweaks on github...)
So volunteer for work. Not that hard, I should think...
Is there a reason to question Eric's stewardship?
Yes.
Knowing Fidel Castro Loco's attitude towards Windows and anything MS in particular, Microsoft and Apple won't be nudged towards supporting FLAC anytime soon.
That must change if FLAC is to remain competitive.
Which means fixes like Wave64 won't happen since Fidel is against any MS creation, including any extended PCM formats devised by MS.
it is open source right?
So no need to ask questions, just fork it under a new name "flac2", make a nice page on what it can do and what is planned to do, how to use under linux/win/osx/*bsd, then you have coders and advertisers and we took over the world in a month or so. Also industry and their jumppods (strong support and advertising for multiplatform audio players, like DeaDBeeF perhaps, VLC, dunno) should be forced to support it, nice legal advisor (or better a team of them vampires) should step in here.
(A nice hi-def picture of Josh holding a cigar with a title: "He knows audio" should also be considered)
@Jensend - flac does not hugely need massive development, it has strong open source roots, so what exactly can xiph offer flac now? FLAC needs industry contacts and marketing right now, exactly what xiph is not doing.
(emphasis mine)
Again, FLAC has been with Xiph for around a decade. And actually having the project under the umbrella of something like Xiph, which is at least somewhat known in "the industry", does not sound much worse than having it under the umbrella of "A Group Of People From An Internet Forum" (even though, of course, HA is excellent in a lot of ways)
Also note that Xiph is at least somewhat trusted in engineering formats, keeping the specifications stable, and maintaining stable reference implementations. Xiph also has demonstrated the ability to work within standards organizations like the IETF. So, personally, I'm very much comfortable with the FLAC specification being maintained at its current location. Then, again, I'm biased, having been an occasionally useful Xiph minion.
Of course, nobody will stop anyone from creating their own FLAC implementations or from simply forking the reference code. But then again you concede that FLAC "does not hugely need massive development". I also am pretty sure that patches to the code base with good quality will be accepted.
So instead of "taking over FLAC" I'd very much recommend offering a helping hand where needed (as individual or as a group). One obvious area where help may be appreciated is the website, which indeed is looking like 1997 and also is outdated content-wise.
The website situation is not much different from old theora.org (which used to look like http://web.archive.org/web/20070830120311/...www.theora.org/ (http://web.archive.org/web/20070830120311/http://www.theora.org/) ): I volunteered to transfer the site to the new design, and I "got the job" without any difficulties despite merely being a longtime IRC lurker beforehand. So I know for sure that contributing within Xiph is very much possible.
AFAIK the future Xiph's format Ghost will support lossless. But it won't be ready any time soon.
I'm honestly not really interested in formats that support both lossy and lossless mode. It's purely my opinion, but I like knowing that if I have a FLAC file that I have an exact copy of the audio that was encoded.
Aside from whether or not it's a good idea, it's also purely a thought problem right now, even moreseo than Ghost itself. I was thinking about lossles output primarily because I'm already using lossless lifting schemes in Ghost. Lossless still has a greater chance of making no sense than making sense in the end.
In short-- talking about lossless in Ghost is purely hypotheitcal cocktail party small talk, even moreso than Ghost itself. There are many bigger fish to fry in the next few years. Don't hold your breath for Ghost, especially don't hold it for Ghost Lossless.
The only problem I have with flac under Xiph stewardship is I wish there was a more effort put into their QuickTime plugins which desperately need a 64-bit update.
I hope xiph taking over flac doesn't interfere with that.
If I'm not mistaken, it is already xiph.org that makes DirectShow filters for Windows, and from reading their list it appears they are very cautious about changes.
For example back in 2008 there was a lot of discussion about how to include album art, they didn't want to do it in a way that would break some hardware players as several of the multiplex solutions did. I have to respect that, if I get an Ogg Vorbis player I don't want to have to worry about whether my ogg vorbis will play on it.
flac seems done to me, I don't know what else could be added, other than possible bug fixes that may pop up from time to time as libraries it depends upon change.
I agree that I want my lossless and lossy codecs separate. Shorten I believe was capable of both, at least as far as concert bootlegs go it seems shorten has been replaced by flac as the preferred lossless. I don't know why, but I certainly prefer flac, especially oggenc can take a flac file as direct input and preserves the tags.
As I said, not gonna happen when the current maintainer is a complete FOSS zealot.
Support for 16-bit float samples would be nice too.... (even if simply processed as 16-bit integers!)
As I said, not gonna happen when the current maintainer is a complete FOSS zealot.
I doubt this has anything to do with ideology. Probably just no one with a 64 bit Mac.
I hardly doubt it this has anything to do with ideology. Erik has been for years a staunch GNU/Linux supporter. Just look at the mess he made with the FB2K resampler debacle.
Maybe it's an aside but I see flac as having untapped potential for support in verious audio production software due to its open-ness and fast decoding speed. Yet few if any of major program support flac including Steinberg Cubase and Adobe Audition and I know of no software sampler format that uses flac. If this is a result of leadership that is overly concerned with FOSS then that's just a sad state of affairs.
I hardly doubt it this has anything to do with ideology. Erik has been for years a staunch GNU/Linux supporter. Just look at the mess he made with the FB2K resampler debacle.
I'm generally an optimist, but in this case I think you are being too generous. Yes, Erik made a mess of the Secret Rabbit and foobar2000 issue - but I don't see any inherent conflicts between GNU/Linux and foobar2000. I think Erik's record on his self-created Secret Rabbit vs foobar2000 issue showed spectacularly poor business judgment in defending his interests as well as the FOSS community, which does not bode well for FLAC. If the viability of FLAC was exclusively related to coding proficiency, perhaps Erik would be up to the task, but FLAC's viability is much more closely tied to engaging stakeholders, marketing and communicating - all of which Erik has been unwilling or unable to do. If anyone tied to xiph disagrees with that assessment because whatever Erik has been doing in those areas has been secret or deemed not worthy of sharing in a plainly-stated manner, I encourage you to change your assessment of what to share in a plainly-stated manner.
Regardless what anyone thinks about the past, I see no excuses for xiph not immediately communicating a clear, concise document describing the goals and plan for FLAC. xiph has had years to communicate a path forward for FLAC and has failed to do so. If that doesn't happen fairly quickly, rather than fight or complain I agree it seems best to fork the code and proceed with much more effective marketing and communication. When it comes to credibility, I'll take Spoon's views any day over silence or Erik's views.
So it seems Josh is no longer working on FLAC, I am concerned that merging into xiph might not be best for FLACs future...(it is nothing personal against xiph), FLAC has a window of opportunity to become the defacto lossless codec, but without strong management it will not (and in 4 years everything will be in Apple lossless, or some such)
Regardless of what happens with FLAC's development, I fear that we are moving to a closed lossless world anyway. I use ALAC for my needs but I want FLAC to survive as it is a form of competition for Apple's developers. It serves as a means of motivation for them to get things rolling again so that FLAC provides a better means of acting as a lossless archive so that Apple's developers feel they have to live up to some standard. Otherwise the people behind ALAC will become lazy and no improvements will come from them. I don't think FLAC will ever become the "defacto lossless codec" simply because Apple and Microsoft are both pushing their own things. That still doesn't mean that FLAC can't improve on where it currently stands and become a standard that others can live up to.
So it seems Josh is no longer working on FLAC, I am concerned that merging into xiph might not be best for FLACs future...(it is nothing personal against xiph), FLAC has a window of opportunity to become the defacto lossless codec, but without strong management it will not (and in 4 years everything will be in Apple lossless, or some such)
Regardless of what happens with FLAC's development, I fear that we are moving to a closed lossless world anyway. I use ALAC for my needs but I want FLAC to survive as it is a form of competition for Apple's developers. It serves as a means of motivation for them to get things rolling again so that FLAC provides a better means of acting as a lossless archive so that Apple's developers feel they have to live up to some standard. Otherwise the people behind ALAC will become lazy and no improvements will come from them. I don't think FLAC will ever become the "defacto lossless codec" simply because Apple and Microsoft are both pushing their own things. That still doesn't mean that FLAC can't improve on where it currently stands and become a standard that others can live up to.
ALAC is now open, no? Or are there pesky software patents hindering its adoption in FOSS ??
I like flac because it comes with my operating system (Linux) but other than possibly encoding/decoding times which could be improved in ALAC I don't have anything in particular against it as long as software patents aren't an issue.
FLAC is nice because it uses vorbis comments - that and it is fast, but that doesn't make it irreplaceable.
Yet few if any of major program support flac including Steinberg Cubase and Adobe Audition and I know of no software sampler format that uses flac. If this is a result of leadership that is overly concerned with FOSS then that's just a sad state of affairs.
Features like FLAC support will only be added if there is business incentive. Business incentive arises from user feature requests. So, hypothetically speaking, what can FLAC leadership do? Also: What can FLAC leadership do what the users of those mentioned products cannot do?
Keep calm now. A “hostile takeover” -- or anything that remotely looks like that or a credible threat to it -- is potentially very harmful to the format and by that, to both Xiph and the entire realm of free media formats.
And although I do not know Mr EdCL, I am a bit surprised to see the way FOSS is turned into an argument here. FLAC has been FOSS all the way. (And if anyone wants to quarrel over 'which' FOSS and claiming that the developer is too much of a GNU fanboy: RMS' view on the matter (http://lwn.net/2001/0301/a/rms-ov-license.php3).)
The only problem I have with flac under Xiph stewardship is I wish there was a more effort put into their QuickTime plugins which desperately need a 64-bit update.
I hope xiph taking over flac doesn't interfere with that.
(emphasis mine)
Again, FLAC has been with Xiph for like a decade. Also, provided nothing changed since the FAQ was last updated, the status of a 64 bit version of XiphQT is covered here:
How do I make XiphQT work with iTunes on 64 bit Mac OS X?
Apple doesn't publish a 64 bit API for Quicktime, so the current XiphQT components are 32 bit.
http://www.xiph.org/quicktime/faq.html#faq_itunes_64bit (http://www.xiph.org/quicktime/faq.html#faq_itunes_64bit)
If this is still the case there will be no 64 bit QuickTime components, no matter what the stewardship.
Keep calm now.
(http://stancarey.files.wordpress.com/2012/04/father-ted-careful-now-down-with-this-sort-of-thing.jpg)
A “hostile takeover” -- or anything that remotely looks like that or a credible threat to it -- is potentially very harmful to the format and by that, to both Xiph and the entire realm of free media formats.
Of course, no one individual or small group should be too aggressive with their opinions on a community-based project. And, helping to avoid such scenarios, I agree with those who feel that – if careful consideration suggests that it’s necessary (perhaps I should scare-quote that) – a fork is preferable to, and more feasible than, somehow assuming control of the entire branch. Most simply, the fact is that the founder has handed administration of the main branch to a particular organisation and on a finer scale a particular person, and there’s not a huge amount that can be done about that right now, I don’t think.
And although I do not know Mr EdCL, I am a bit surprised to see the way FOSS is turned into an argument here. FLAC has been FOSS all the way.
No one’s saying it hasn’t. Rather, the issue is whether the current maintainer’s interpretation of FOSS might be counterproductive. I don’t know enough to take any side, but I don’t think anyone’s criticising/blaming the FOSS model in principle.
Apple doesn't publish a 64 bit API for Quicktime, so the current XiphQT components are 32 bit.
http://www.xiph.org/quicktime/faq.html#faq_itunes_64bit (http://www.xiph.org/quicktime/faq.html#faq_itunes_64bit)
If this is still the case there will be no 64 bit QuickTime components, no matter what the stewardship.
Yeah, that kind of bites, shame on Apple.
I wish they would use standard ReplayGain as well - but Apple is kind of quirky that way.
Flac's biggest issue IMO is broad knowledge from the public. However, it's better to do a 'top down' approach to getting the format used. I work in video production where we keep MASSIVE amounts of uncompressed audio for use in editing suites. Professionals use lossless audio. Getting FLAC adopted into Final Cut Pro, Premiere Pro, etc would be great for its popularity. If our editing software supported flac we would use it for massive archives of audio. More importantly perhaps would be getting music production software to give preference to exporting music as flac. Also recording INTO flac instead of wav would be a huge boost... tackles the problem at the source by doing away with the need for wav, dont make people encode from wav, do it for them.
I hardly doubt it this has anything to do with ideology. Erik has been for years a staunch GNU/Linux supporter. Just look at the mess he made with the FB2K resampler debacle.
This level of paranoia is not productive. If you have some score to settle you should probably keep it to yourself.
Not productive? I call it being completely realistic.
Such a downturn for the economy, such a downturn for IT.
I miss that heat in 1998 - 2002 when the IT thinkers boomed with their ideas!
I think the same is for the MP3 format. It's so behind AAC and it still haven't got a open source competitor.
Yet few if any of major program support flac including Steinberg Cubase and Adobe Audition
Cubase 6.5 supports FLAC import, playback and export.
Audition supports plugins and there has been a FLAC plugin (called filter) for Audition even when it was still Cooledit (Pro). It is also linked on the FLAC download page (http://flac.sourceforge.net/download.html).
Other popular Audio editors like Wavelab or Audacity include FLAC support too.
I don't see your point.
Other popular Audio editors like Wavelab or Audacity include FLAC support too.
Flac in Wavelab is only available since version 7.1, the very newest release afaik. For wavpack for example the wavpack developer released a plugin alrerady in 2006 to make it work.
Edit: looked it up. The wavpack plugin was written by someone else, not the wavpack developer himself. http://wavpack.gl.tter.org/ (http://wavpack.gl.tter.org/)
Eric had assured me he would reply addressing some of the concerns directly to this thread (a reply within a week, four weeks ago), my email requesting an update (2 weeks ago) has had no response.
Now if you do not mind I will get back to my film I am watching - The Abyss...
I hardly doubt it this has anything to do with ideology. Erik has been for years a staunch GNU/Linux supporter. Just look at the mess he made with the FB2K resampler debacle.
FLAC needs advocates and champions to get support into all players and devices, even closed source. I just read about the topic above, and think he might hinder such advocacy.
One obvious area where help may be appreciated is the website, which indeed is looking like 1997 and also is outdated content-wise.
I agree. Who do I contact regarding this?
I'm not that good at web design, but I could at least submit some news etc.
Steinberg Cubase and Adobe Audition
Both of those actually support FLAC natively.
(Information like this could be added to the FLAC website.)
Meanwhile, you can also vote for FLAC support in Windows Phone (http://windowsphone.uservoice.com/forums/101801-feature-suggestions/suggestions/2828896-flac-music-support) (no need to log in). Supposedly Microsoft actually reads those requests.
I think Xiph should push to make FLAC an ISO-standard (or IETF-standard like Opus).
I think that would help it become the mainstream standard it deserves to be.
Does anyone know if this has been tried?
I think Xiph should push to make FLAC an ISO-standard (or IETF-standard like Opus).
I think that would help it become the mainstream standard it deserves to be.
IETF usually involves Internet standards; stuff that would be used over the internet. Lossless audio requires a lot of bandwidth, but with today's internet speeds it might be feasible. Streaming FLAC won't work on my connection
Opus satisfies a lot of use cases for use on the Internet like low-delay, low-bandwidth, packet loss etc.
I think Xiph should push to make FLAC an ISO-standard (or IETF-standard like Opus).
I think that would help it become the mainstream standard it deserves to be.
IETF usually involves Internet standards; stuff that would be used over the internet. Lossless audio requires a lot of bandwidth, but with today's internet speeds it might be feasible. Streaming FLAC won't work on my connection
Opus satisfies a lot of use cases for use on the Internet like low-delay, low-bandwidth, packet loss etc.
Yes, ISO would be the most fitting standards-body.
FLAC needs >2G support
More or less, they reached a point of maturity. But they still need to do improvements (2gb limit for example).
This bugfixed version http://www.foobar2000.org/encoderpack (http://www.foobar2000.org/encoderpack) does, as you can see from the news here: http://www.foobar2000.org/?page=News (http://www.foobar2000.org/?page=News)
AFAIK the future Xiph's format Ghost will support lossless. But it won't be ready any time soon.
I'm honestly not really interested in formats that support both lossy and lossless mode. It's purely my opinion, but I like knowing that if I have a FLAC file that I have an exact copy of the audio that was encoded. If I want audio in a form where I don't mind loss, then there are plenty of choices out there. Mixing lossy and lossless audio in the same codec does nothing but confuse the issue and introduce too much chance of mistaking a lossy version as lossless and introducing loss into a signal chain that was intended to be lossless.
Imagine if mp3 had a lossless mode and you had the hordes of noobs out there mangling their encodes because they don't understand the difference. You'd have people loading sansa clips with lossless mp3 files then complaining because they can only get 5 or 6 albums on it. Then you'd have "CD backups" loaded with 128Kbps CBR files. You know it would happen, A LOT.
Keep it simple.
You couldn't have explained better why I don't like WavPack.
Opensource projects are too easily abandoned, what does it really take to switch website like Xiph was saying? Don't want to be rude but people don't really have half an hour to do this? I'd love too see FLAC becoming the default lossless codec of every system.
Oh this nonsense has been debunked before. Wavpack lossless files have a 'lossless' flag in the tag profile and most people are using lossless mode exclusive or a hybrid / lossless mix. WV Lossy files have a 'lossy' flag. You don't know the authenticity of a file unless you encode it yourself. Just because a FLAC file doesn't support lossless doesn't mean the source isn't lossy. In some cases it is on P2P networks and likewise LAME V0 / 320k files have a sharp 16khz cutoff . You don't know the a flac file hasn't been tampered with . No one will get a wavpack lossy file unless using the -b switch in the encoder explicitly.
Oh this nonsense has been debunked before. Wavpack lossless files have a 'lossless' flag in the tag profile and most people are using lossless mode exclusive or a hybrid / lossless mix. WV Lossy files have a 'lossy' flag. You don't know the authenticity of a file unless you encode it yourself. Just because a FLAC file doesn't support lossless doesn't mean the source isn't lossy. In some cases it is on P2P networks and likewise LAME V0 / 320k files have a sharp 16khz cutoff . You don't know the a flac file hasn't been tampered with . No one will get a wavpack lossy file unless using the -b switch in the encoder explicitly.
Yeah ok, tell everyone to check the tag. This is how it works mostly: extension = .wv? Must be lossless, or: "it's wavpack it can't be lossy!".
Of course people convert lossy to lossless even with a lossless only codec but the chance to exchange lossy files is reduced.
How exactly is a wavpack user gonna end up with a lossy / lossless confusion - unless they have seriously diminished brain function ?
The lossy mode is disabled by default. I believe shorten also has a lossy mode.
Who is publishing wavpack files these days ? I am not aware of any commercial vendors but I have seen stuff P2P and was always labeled 'wavpack lossless - EAC'.
You couldn't have explained better why I don't like WavPack.
Opensource projects are too easily abandoned...
so, when FLAC was abandoned, how did someone pick it up again? because it was open source. a closed source project can be abandoned just as easily, but then no one can continue the work without the source. in this case, and most others, open source is better.
and even if it were to happen that anyone were to distribute a lossy WavPack file as lossless, the recipients would become aware of this probably as soon as:
- looking at the bitrate.
- looking at the tags.
- looking at the file size.
as said, you cannot encode a lossy WavPack file without making an educated effort at doing so.
I don't get it.
Container formats like WAV, AIFC, CAF, AVI, MP4, MKV, MOV can actually contain many different codecs under the same container/file extension, and it might indeed be confusing to a noob.
On the other hand, I don't think Wavpack is so much confusing... You are not required to get codec packs or something from somewhere. If a player supports Wavpack, it will play it. At least much simpler than MP4 codecs. Isn't it?
BTW you can still use lossyWAV + FLAC, and it actually works fine.
And if it is so much confusing, one can just name a file like .hybrid.wv or something, I suppose.
How exactly is a wavpack user gonna end up with a lossy / lossless confusion - unless they have seriously diminished brain function ?
By converting all their .wv files to .flac, without thinking that some of their .wv's were lossy? Which could of course happen if the user retrieves .wv from TOS9-uncompliant sources. Ignorance is bliss, thus so is transpacence.
Or by messing up folder structure? Myself I apply one-folder-per-disc, but even if the folder has artist + year + albumtitle, so does the filename. Will easier detect it if I manage to drag+drop by mistake. Also, those pesky pre-emph'ed CDs are not only tagged as such, they are stored in a different lossless format (WavPack, actually – my codec of first choice is FLAC), in case I manage to mess up a tag.
Some of this is pure naivety. lossyFLAC exists The trivial ability to transcode your entire playlist (WAV, mp3, WV, etc etc) into FLAC exists. Bad rippers exist.
It's up to you what level of paranoia you want to adopt.
Cheers,
David.
FLAC is a great format.
But given that the market is moving to thinner and lighter devices a storage size will remain small compared to one of a desktop devices.
Lossy formats will remain more attractive alternative for a long time.
It's very uncommon that somebody uses lossless on his/her smartphone or tablet with 16-32 GB or so. Oh, and time delay to transfer big files to mobile devices quite uncomfortable. Too many limitations to my taste.
Class 10 64GB µSDHC card in phone, FLAC to phone in not too much time at all.
I keep a collection of 8 GB cards ($4 each) and load each with a bunch of FLAC files. That way I don't worry about how long it takes to reload one. Each card then has about 20 hours of music, which is longer than the battery in the clip+ lasts.
I use FLAC as my playable local network archive. If I'm moving music to a mobile device then I transcode it on the fly from those FLAC files. My machine can transcode the files faster than any of my players or thumb drives can write, so speed is not an issue.
I find this thread to be a fascinating look into a codec that I'm just starting to use (yes, I'm a latecomer).
So here's a simpleton's question: am I correct that Sourceforge still contains the latest FLAC binaries? And that there are no "variant" versions available (akin to halb27's -V0+ variant of LAME)?
So here's a simpleton's question: am I correct that Sourceforge still contains the latest FLAC binaries? And that there are no "variant" versions available (akin to halb27's -V0+ variant of LAME)?
Yes, the official reference binaries are still hosted on SourceForge. But there are different FLAC encoders out there using different approaches to encoding files - typically for better encoding speed, better compression, etc. However, since they're all lossless, the actual data stored is bit-for-bit identical no matter what approach is used. So the encoder doesn't really matter.
I find this thread to be a fascinating look into a codec that I'm just starting to use (yes, I'm a latecomer).
So here's a simpleton's question: am I correct that Sourceforge still contains the latest FLAC binaries? And that there are no "variant" versions available (akin to halb27's -V0+ variant of LAME)?
There is also a bugfixed version allowing >2GB files. You can get the .exe from inside this archive: http://www.foobar2000.org/encoderpack (http://www.foobar2000.org/encoderpack)
However, since they're all lossless, the actual data stored is bit-for-bit identical no matter what approach is used. So the encoder doesn't really matter.
Should be pointed out that not all FLAC files are streamable, though. The safe option is to use the reference encoder (and avoid the --lax command-line option ... I guess beginners will be more than satisfied with -8).
Class 10 64GB µSDHC card in phone, FLAC to phone in not too much time at all.
An increment happens for all aspects. A storage, resolution, performance.
Phones are getting HD displays. Now people want to store a higher resolution photos, HD videos and bigger applications. 64 GB isn't exclusively for audio files.
Should be pointed out that not all FLAC files are streamable, though. The safe option is to use the reference encoder (and avoid the --lax command-line option ... I guess beginners will be more than satisfied with -8).
Thanks for the tip, as I was about to ask where I could find some of the alternate versions which allow for compression beyond -8.
But yes, I've found -8 -p to be more than satisfactory in most cases. That said, I have been surprised at the apparent complexity of some of my favorite tracks, as FLAC could only go to a .800 or so ratio on some of them, even with these settings.
You might try and see how TAK does on them.
But yes, I've found -8 -p to be more than satisfactory in most cases. That said, I have been surprised at the apparent complexity of some of my favorite tracks, as FLAC could only go to a .800 or so ratio on some of them, even with these settings.
If you want to be completely and uncompromisingly lossless, that's something you'll have to accept if you like any pop or rock music made after the late 1990s.
It's not uncommon to find lossless bitrates of around 1000 kbps in albums from the last few years which are 'competitive with their peers' in terms of loudness on shuffle play - i.e. they are victims of the Loudness War. If the volume is very high, distortion is introduced to make it so high, which is less predictable, causing lossless encoders to use more bits encoding the error between their prediction and the actual values. Also the bottom bits are full of much more random noise floor below the non-random music (what's not predictable is called the residual, which takes up most of the space of a lossless file) and a lossless encoder dutifully encodes every last bit of the noise floor too, which might be thought of as 10 to 13 bits per channel of essentially random data in some extreme Loudness War victims!
As greynol says, TAK will probably perform a little better than FLAC on these, though don't expect miracles!
There are some ways to overcome this needless bloat, which while not 100% lossless compared to what's on the CD, are effectively lossless according to the question "
If this sound were mastered at a reasonable level that's still transparent, what would lossless look like?". In other words it's as though you re-mastered to a normal volume (but kept the distortion) then encoded to lossless.
- Remaster at a sensible volume, e.g. 83 to 89 dB SPL like a classical or early 1990s CD
Bitrate: 650-800kbps perhaps - Use ReplayGain Apply Album Gain (with clipping prevention) and dither e.g. in foobar2000 Converter. Changes original volume, but saves reaching for volume control in shuffle.
- Use lossyWAV (http://wiki.hydrogenaudio.org/index.php?title=LossyWAV) to make filename.lossy.flac
Bitrate: 440-550 kbps (standard, high or extreme settings) - never shown non-transparent at standard or above. Becomes fully lossless in quiet tracks or deep fades. No low pass filtering. CUEripper / CUETools includes early version (with no adaptive noise-shaping so slightly higher bitrates) but very easy to use when ripping or converting.
- WavPack Lossy mode
Bitrate: 384, 448 or 512 kbps typically. Doesn't analyse noise floor like lossyWAV but very robust around 512. Becomes fully lossless in deep fades or very quiet tracks, no low pass filtering.
I have a new iPhone 5, my first Apple device. My audio collection is all FLAC. In the app store, I have my choice of about 10 players that handle FLAC, ranging from free to $10 (I like HD Player and Capriccio, both of which support ReplayGain), so the lack of native Apple support doesn't bother me (I don't use iTunes).
However, I only have the 16GB iPhone, so I don't store much of my FLAC stuff on the phone. I've used dbPoweramp to convert a few FLAC albums to Nero AAC using high bitrate VBR, and frankly I can't hear much of a difference even with a good pair of earbuds. Until Apple starts supporting hi-res audio (which I think they will do simply to charge more for the music), they're not going to significantly upgrade the DACs in their portable products. I'm very impressed that they managed to fit any DAC in such a small, thin device as the iPhone 5. With the faster dual-core CPU, they could have gone DSP-only.
IMO, the current Cirrus Logic DACs aren't good enough to warrant the extra file size of FLACs for portable use. Interestingly, Apple has included a Wolfson DAC in the Lightning-to-30-pin adapter, so they're still interested in pushing quality sound out to external playback devices. And Lightning can output both digital and analog signals to external devices.
I haven't tried Opus yet, but if it's as good as the reports indicate the future for portable lossless files of any kind may be limited. The masses are all streaming now, they don't want to mess with managing a collection (from what I've seen of the new iTunes, all the improvements have been made to the store experience, not collection management). I have a feeling that FLAC is going to be relegated to the music server/HTPC segment, and its days as a portable format are limited, even as storage gets cheaper.
Are you prepared to substantiate either of those sound quality claims even if one of them is only expressed as an opinion*?
Wolfson vs. Cirrus Logic?
High bitrate Nero AAC vs. lossless?
(*) opinions are not in any way exempt from TOS #8.
Are you prepared to substantiate either of those sound quality claims even if one of them is only expressed as an opinion*?
Wolfson vs. Cirrus Logic?
High bitrate Nero AAC vs. lossless?
(*) opinions are not in any way exempt from TOS #8.
No claims were made. I don't know if Apple prefers Wolfson to CL, they've used both in earlier products. I suspect the CL was the smaller chip, so it went in the phone. There have been comments made by reviewers that the iPhone 5 audio is a notch below the iPhone 4S sound, so maybe the Wolfson in the adapter is a larger, better DAC than the tiny CL they used. I was just making the point that they bothered to put a DAC in the adapter--must have had a reason, since it makes the adapter more expensive.
As for FLAC vs. AAC, I said I couldn't hear much difference with
my setup. If I had a pair of $500 Sennheiser IEMs instead of my $150 Shures, I could probably tell the difference--but the iPhone only cost me $200, so I'm not going that route. As always, YMMV. I'm transcoding to 300 VBR AAC, so the quality's pretty good, but I'm not claiming it's as good as lossless. It's just good enough for my usage.
You can call off the mods now.
IMO, the current Cirrus Logic DACs aren't good enough to warrant the extra file size of FLACs for portable use. Interestingly, Apple has included a Wolfson DAC in the Lightning-to-30-pin adapter, so they're still interested in pushing quality sound out to external playback devices. And Lightning can output both digital and analog signals to external devices.
[…] No claims were made. […] I was just making the point that they bothered to put a DAC in the adapter--must have had a reason, since it makes the adapter more expensive.
(emphasis mine) Those are claims about the quality of DACs, and they need to be justified. You've been here since the beginning of HA, you should know this.
Also, the Lightning connector is all digital, there's no analog line out. That's why they had to put a DAC inside the Lightning to Dock adapter. Quality had nothing to do with it.
FWIW, RMAA tests of the Cirrus Logic DACs in Apple's latest products show high linearity and low distortion.
If I had a pair of $500 Sennheiser IEMs instead of my $150 Shures, I could probably tell the difference
Another claim that needs justification.
Those are claims about the quality of DACs, and they need to be justified. You've been here since the beginning of HA, you should know this. Also, the Lightning connector is all digital, there's no analog line out. That's why they had to put a DAC inside the Lightning to Dock adapter. Quality had nothing to do with it.
FWIW, RMAA tests of the Cirrus Logic DACs in Apple's latest products show high linearity and low distortion.
If I had a pair of $500 Sennheiser IEMs instead of my $150 Shures, I could probably tell the difference
Another claim that needs justification.
OK, I give up, I retract both my earlier posts. I'd still like to know why Apple chose Wolfson over Cirrus Logic for the connecter DAC. Price? Quality? They already had stacks of them in a warehouse? I have no idea, I just made the quite possibly mistaken assumption that the company preferred the Wolfson for quality reasons. I won't make any assumptions anymore.
As for the Sennheiser vs. Shure remark, you're quite right. I don't want to get into a Head-Fi-style debate over the relative quality of stock IEMs. My point was that my Shure set is certainly not in the top tier of IEMs--I have no first-hand experience with the Sennheiser line--and that higher quality earbuds would very likely reveal more differences between my AAC files and my FLAC files on the iPhone CL chips. In any case, I certainly don't have "golden ears" and was just speaking from personal experience using the setup I have. I don't need or expect an audiophile experience on a phone anyway.
Spoon opened this thread speculating about the future of FLAC, and I just don't see it having much of a future as a portable format in a world where most people are getting their music from the iTunes store and Spotify/Pandora and don't even know what a DAC is. I think it already is and will continue to be the standard container format for home music servers, HTPCs, and multi-TB hard drive music collections like mine. ALAC and the others are very minor players in that space.
Apologies all around if I ruffled HA feathers with my posts.
It's too bad this topic had to take tangential paths, but that's what happens when people choose to defend positions that should not be defended.
A tangential path on FLAC sucking because it is not CBR can be found here:
http://www.hydrogenaudio.org/forums/index....showtopic=98015 (http://www.hydrogenaudio.org/forums/index.php?showtopic=98015)
If the future of FLAC is really in question, why hasn't it been brought up on flac-dev? It's not like you need to know the secret handshake to post there (even if one is directly challenging the quality of the current maintainership).
The fact that Eric has (up until now) ignored the concerns raised here, says plenty about its current stewardship, perhaps they were not worthy concerns...
However I fear it is a case of:
(http://www.ostrichheadinsand.com/images/ostrich_head_in_sand.jpg)
This kind of makes me wonder if Justin Ruggles (the owner of FLAKE) would be interested in taking over. And if the community would accept that.
This kind of makes me wonder if Justin Ruggles (the owner of FLAKE) would be interested in taking over. And if the community would accept that.
No
I think code development and networking can be seperate. Not independent of course, but I think it's realistic to let xiph.org maintain the api, and if any needs for change arise because networking introduces new users, and new demands, that's when networking people can make a request of the development team. If that doesn't work, well that's a bridge you can cross when you get to.
I am willing to contribute my ideas with anybody. Here is a start with a fan page, nothing complete just what I've got together before going in to work: http://www.facebook.com/pages/FLAC/5336467...533646726686289 (http://www.facebook.com/pages/FLAC/533646726686289#!/pages/FLAC/533646726686289)
. Some things that I would like to see are: a user-friendly modern website / guide for curious non-tech, every-day windows users; logos / motto pics that can be distributed on facebook; some FLAC-specific merchandise either recommended to xiph.org, or done independently; facebook ads, etc.
The idea behind this not being to make business deals with microsoft after I get off of work, but just to advocate flac to the public, and to hopefully gain more commercial support for the FLAC format by doing so... Spam links to request microsoft to add flac support to windows CE, whatever.
As you may notice, I am not a regular visitor on HydrogenAudio, so my preferred method of contact would be through the facebook page. I did a flac decoding project a couple of years ago, asked some questions here, and tuffy (Josh if I'm not mistaken) helped me out and I really appreciated it. Anyways, I've been curious how things are going with FLAC and I ended up here. I hope to get the ball rolling with like-minded people, and I've left the first page like up for grabs by anyone (it could be yours).
So I search for FLAC on facebook before all this happened and just can't find anything... Then I start a fan page and whatever and go to like xiph.org and there's a link to a Free Lossless Audio Codec page right in front of me asdfasdfasdfasdf. Anyways I'm going to keep it up for now and see what happens.
Back on topic.
Someone wrote a FLAC decoder in native Rust:
https://github.com/sourrust/flac
If FLAC is ever going to be used in the web (in browsers). Servo (https://servo.org) will probably opt to use this native/safe decoder.
One more thing which FLAC needs (to be more suitable for multichannel audio): add suport of WAVEFORMATEXTENSIBLE_CHANNEL_MASK to specification. Problem explained here - https://sourceforge.net/p/flac/bugs/430/