IPB

Welcome Guest ( Log In | Register )

32-bit support, Split from: "The Future of FLAC"
Brand
post Aug 31 2012, 22:21
Post #1





Group: Members
Posts: 312
Joined: 27-November 09
Member No.: 75355



QUOTE (yourlord @ Aug 31 2012, 21:26) *
32-bit support

QUOTE (sshd @ Aug 31 2012, 22:16) *
>2G support

Both of these are important.

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

This post has been edited by Brand: Aug 31 2012, 22:31
Go to the top of the page
+Quote Post
 
Start new topic
Replies
smok3
post Sep 1 2012, 19:40
Post #2


A/V Moderator


Group: Moderator
Posts: 1708
Joined: 30-April 02
From: Slovenia
Member No.: 1922



QUOTE (db1989 @ Sep 1 2012, 11:46) *
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.


--------------------
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung
Go to the top of the page
+Quote Post
jensend
post Sep 1 2012, 21:03
Post #3





Group: Members
Posts: 140
Joined: 21-May 05
Member No.: 22191



QUOTE (smok3 @ Sep 1 2012, 12:40) *
Main users of HD feature will be almost certainly home users
*Sigh.* You couldn't tell he was joking about going around yelling "HD!"? So-called "HD audio" is of zero real value to home users.

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.
Go to the top of the page
+Quote Post
Brand
post Sep 1 2012, 21:47
Post #4





Group: Members
Posts: 312
Joined: 27-November 09
Member No.: 75355



QUOTE (jensend @ Sep 1 2012, 22:03) *
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! wink.gif
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.

This post has been edited by Brand: Sep 1 2012, 21:56
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 16th April 2014 - 09:04