I was glad to see that in audio editing/music making software FLAC gained a lot of support in the last couple of years. I'd say right now most support at least importing FLAC.But 32bit float is used a lot in audio editing, so FLAC could definitely improve there.

EDIT:Also, I remember reading once that FLAC is too loosely defined (compared to ALAC where the rules are more strict regarding number of channels etc.). Don't know much about that stuff myself, but if it's true it's worth looking into. Hardware/software manufacturers want a reliable standard to work with.EDIT2: found it

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 […] A nice hi-def picture of Josh holding a cigar with a title: "He knows audio" should also be considered

Flac HDThey won’t be able to stop themselves throwing money at you.

In seriousness, I wonder whether LithosZA is correct that there’s little point in supporting very high bit-depths and sampling rates. Josh already noted that the main utility (not necessarily use, thanks to the pyrite-ears community; rather, usefulness) of such parameters is in editing/engineering, and while I can conceive of a scenario in which one wants to backup a project without having its uncompressed files take up so much space, I wonder whether that really needs to be a concern or at least a priority. But then again, would it be relatively trivial to add it and keep everyone happy?

In seriousness, I wonder whether LithosZA is correct that there’s little point in supporting very high bit-depths and sampling rates. Josh already noted that the main utility (not necessarily use, thanks to the pyrite-ears community; rather, usefulness) of such parameters is in editing/engineering, and while I can conceive of a scenario in which one wants to backup a project without having its uncompressed files take up so much space, I wonder whether that really needs to be a concern or at least a priority. But then again, would it be relatively trivial to add it and keep everyone happy?

if it doesn't break current decoder then why not? Main users of HD feature will be almost certainly home users (at least thats what i imagine), as a video guy its hard to imagine to have a 30s clip which is 1.x gigs in size and then even care about audio size part.

32-bit floats aren't "higher-definition" than 24-bit in any useful way. A 32-bit float has 24 bits of mantissa precision. Yes, that's one bit more than 24-bit (since the first bit of 24-bit is the sign bit), and the exponent allows higher precision for values near zero, but it's entirely irrelevant since real world ADCs and DACs can't do better than 20 fixed-point bits anyways. None of the extra bits matter at all because they're only representing noise. Random noise is hard for FLAC- or anything else- to compress.

There are two reasons floating point makes sense during editing:

it's easier to code algorithms in floating point because you can often kinda pretend they're real numbers

you don't have to worry about intermediate results being too large and clipping or being too small and losing precision

But it makes zero sense to use floats for archival. Even for backing up a project you're in the process of editing, under almost all circumstances, if you care enough about storage space to use compression and you're willing to wait for a FLAC encode/decode, you might as well also have the audio normalized and stored at 24 bits. You then just convert the 24-bit samples back to float when you load your backup. Nothing of value is lost.

A similar argument applies to ridiculously high sampling rates. If what you care about is how it sounds to human listeners (i.e. you're not doing ultrasonics research - bioacoustics, chiroptology, etc.) then the only reason to have >48kHz sampling rates is to allow for simple, fast filters with wide transition bands when you're editing. None of the extra frequency content matters at all because it's representing stuff that is entirely inaudible. Even for backing up an editing project, in almost all circumstances, if you care enough about storage space to use compression and you're willing to wait for a FLAC encode/decode, you might as well also use a high-quality, narrow-transition-band resampler, downsample, and then upsample when you load your backup. Nothing of value is lost.

So floating point support, ReplayGain support for 192kHz and higher recordings, etc. might be nifty, and those changes might make some people stop complaining, but it's hard to argue that these matter to hardly any use cases or that they should take priority.

But it makes zero sense to use floats for archival. Even for backing up a project you're in the process of editing, under almost all circumstances, if you care enough about storage space to use compression and you're willing to wait for a FLAC encode/decode, you might as well also have the audio normalized and stored at 24 bits. You then just convert the 24-bit samples back to float when you load your backup. Nothing of value is lost.

Normalizing could mess up your levels, no? Say if you'd re-import the files into a multi-track project with the same mixer settings and don't take the necessary steps to ensure you can reapply the settings, including those of amplitude-dependent effects.

I could also imagine FLAC being used for exchanging files over the internet, for example. Using compression 5 or so, it might not add significant time to the encoding (rendering effects/instruments takes time as well).

But perhaps more importantly:

QUOTE (jensend @ Sep 1 2012, 22:03)

So floating point support, ReplayGain support for 192kHz and higher recordings, etc. might be nifty, and those changes might make some people stop complaining, but it's hard to argue that these matter to hardly any use cases or that they should take priority.

Making some people stop complaining can be very beneficial for marketing purposes. A lot of people simply think bigger number=better. Not just housewifes who can't use a computer, even many (influential) enthusiasts, people like Neil Young etc.So, might as well add 64 bit support while we're at it. Imagine the headlines! That is, of course, assuming that it's easy to implement and doesn't cost too much in terms of development time or backwards compatibility. I'm not a developer, I don't know anything about that, so I won't insist.BTW, googling "flac" "32 bit float" gets me 55.400 results.

But perhaps more importantly:[…]Making some people stop complaining can be very beneficial for marketing purposes. A lot of people simply think bigger number=better. Not just housewifes who can't use a computer, even many (influential) enthusiasts, people like Neil Young etc.So, might as well add 64 bit support while we're at it. Imagine the headlines!

Speaking for myself at least, I could not give a hoot about those who are deluded about high resolutions, and I don’t think they should even be considered when deciding upon future development. They can have, at most, yet another FAQ-type resource explaining why their beliefs about inflated parameters are false. But they absolutely should not be pandered to simply for the sake of artificial popularity/conciliation. That would entail that the maintainer(s) passively withhold obvious truths about digital audio at best and actively distort them at worst. I mean, you do know which site you’re on and which site spoon is suggesting take over the reins of FLAC, right?

I'm not sure I agree with what I think you're implying (that adding ridiculously high specs is some sort of deceiving). Also FLAC already supports 32bit fixed point and 655350Hz sample rates, both of which are unnecessary by certain HA standards.Anyway, the 64bit part was mostly a joke, although again, I don't see the harm in adding it. I would disagree with promoting it with statements like "it improves the sound", but I wasn't suggesting doing that.

However, I do believe 32bit float support would be useful, even if it's only used in certain niche cases and not for distribution. (But I should stop repeating myself now.)

I'm not sure I agree with what I think you're implying (that adding ridiculously high specs is some sort of deceiving).

You think wrongly, for I’m not implying anything. I meant exactly what I said (quite clearly, I had thought): The ability to use such resolutions should not be added for the sake of attempting to increase the format’s appeal to people who hold mistaken beliefs about their utility.

QUOTE

I would disagree with promoting [high resolutions] with statements like "it improves the sound", but I wasn't suggesting doing that.

You might not have stated that yourself, and I said neither that you said it nor that you believe it, but you did say that higher resolutions might help to assuage and appeal to those who do believe such myths. So, the two might become effectively equivalent, regardless of your intentions. The spread of falsehoods about higher resolutions is not likely to be decreased, as Hydrogenaudio desires, by their inclusion “for marketing purposes”. Rather, I can imagine gurus of woo interpreting it precisely the opposite way.

If you didn’t meant that the next maintainer(s) of FLAC should add support for higher resolutions in order to pacify those who wrongly believe that “bigger is better” in this context, you shouldn’t have chosen a configuration of words that says just that.

Well, I shouldn't have said "normalized." You don't want to switch from float to 24-bit if you have any tracks that are currently clipping, and you may not want to do it if you have any tracks to which you will later add 24dB or more of gain. That's all you need though, and I think those aren't too terrible of limitations.

If you're sending someone else an in-progress multitrack project, your DAW software should be exporting a project file with at least the gain to be applied in mixing, intended channel, track start/end time, etc for each track, not just a collection of raw FLACs. It wouldn't be hard for software to implement a compressed project file format with the audio data stored as FLAC and take care of sample format conversion (e.g. float-int-float) and normalization/gain issues as part of the project file.

Real-time losslessly compressed audio transfer over the Internet makes no sense. You can't get much of a bandwidth savings with lossless without introducing a fair bit of delay, and since no lossless codec can guarantee that its output will have a lower bitrate than the original, your internet connection would have to have sufficient bandwidth for the uncompressed original anyways.

The FLAC format supports 32-bit fixed point, and from what little I understand it wouldn't be too difficult to create an encoder that could actually produce such files. In most ways relevant to audio, 32-bit fixed point provides more precision than 32-bit float*. It's just that nobody has cared enough about that extra precision enough to bother implementing it; again, real world ADC/DACs can't do better than 20bit fixed point.

As far as marketing advantages, the famous Lincoln quote about fooling people applies quite well to marketing imaginary benefits. In the long run, adding snake oil to FLAC is not going to help anybody.

@skamp: That is not a clipped 32bit float track. The downconverted to integer (be it 16, 24 or whatever bits) will. And that's the whole point.

All the float talk is about mixing and mastering. Currently, applications already use some sort of compression for samples (examples include DPCM, zip-like techniques, or even the compression of soundfonts with sfark/sfpack). In fact, FLAC has been proposed or used in some formats.The ability to use 32bit float in those scenarios allow for more flexibility during the process.

32 bit support would be a great addition. I record to FLAC 24 bit using Reaper but when I apply effects to items on a track a have to choose WAV 32 bit float since FLAC does not support it. A shame because it would be great if I could use FLAC all the way. Regards.

32-bit floats aren't "higher-definition" than 24-bit in any useful way. A 32-bit float has 24 bits of mantissa precision. Yes, that's one bit more than 24-bit

the point was i will not bother with compression/conversion in pro environment (with 40 tera fiber channel drive), so all thats left is crazy home users (and their placebo power). < but thats only my view (i do know the business quite well thought).

If you didn’t meant that the next maintainer(s) of FLAC should add support for higher resolutions in order to pacify those who wrongly believe that “bigger is better” in this context, you shouldn’t have chosen a configuration of words that says just that.

Right, I should have separated those first two sentences when talking about popularity (and "marketing").But--at the risk of stating the obvious and repeating again--let me clarify: If FLAC can benefit from increased popularity, then it's something the developers should take into account. Of course, not by selling snake oil, but with technical improvements, which can (at least potentially) be useful and make some people happy at the same time.

If someone thinks those improvements are good for the wrong reasons ("it sounds so much better") it's unfortunate, but if this helps make FLAC more popular and survive in the long term, I see it as a net positive result.There's only so much you can do to keep people informed... and FLAC (not) including 'high res' capabilities in its specs IMO doesn't make a difference in this regard. Those who want or need to learn about this stuff will always find out what's what.And I would be very much in favor of a FAQ on the official FLAC page, pointing out that good AD/DA converters yield around 20bits of dynamic range.. that 24bit is already overkill and that 32bit float is only useful for certain applications. That should keep uninformed speculations at bay.

Unless we want to limit FLAC to a final-product-distribution format, but I don't (yet) see a good reason for that.

In that sense, even my 64bit suggestion was semi-serious, after all 64bit float is used in some DAWs.(here's a thread about its potential/theoretical usefulness, including a quoted post about how to bring 32bit float to its limits--I haven't tried that myself, don't know how valid it is)

(here's a thread about its potential/theoretical usefulness, including a quoted post about how to bring 32bit float to its limits--I haven't tried that myself, don't know how valid it is)

If one reads that well, it just says that there is a mathematical difference doing operations in 32bit float versus 64bit float, and that if one increases the *difference* of both signals, it can be seen/heard. Well... yes... and the same happens if you get 128bit float versus 80bit float versus 64bit float... That's completely irrelevant to *audio*.

64bit float *math* is required in several audio algorithms to prevent audible problems, but 64bit float audio pipeline is relatively unnecessary versus 32bit float, because although you might be accumulating error, you're accumulating it on the 24th bit of the mantissa. How many operations does one need for that to become audible?

In the 90's, the audio pipeline of audio applications was 16bit INTEGER. (x87 floating point operations were too slow)

I'd say it is a lesser evil to jump on the supporting-way-too-uselessly-high-resolutions bandwagon than having to resort to a “yeah, conversion to FLAC will be lossy but it will be audibly transparent”.

I thought even 24-bit wav was pointless as far as the human ear is concerned, why would we worry about 32-bit?Hell, I seem to recall they originally proposed 12-bit for CDs.

I guess there may be production tools that work with higher than 24-bit but do they really need to?As a music consumer, I'm interested in what real world benefits there are to it, because my understanding is that there really aren't any. Human ears can't distinguish it anyway.

I guess what I'm worried about is a stable product going through changes that aren't going to benefit us anyway.

>2GB support I can understand wanting. The use may be limited but I don't want an artists creativity to be hampered by how much the file format can support, and if an artist is going to do something that big, I sure as hell hope it is distributed compressed ...