[flac-dev] Support for ultra-high sample rates?

[Con Kolivas]

On Tue, 2 Jun 2020 at 19:13, Olli Niemitalo <o at iki.fi> wrote:
>
> Browsing the sources, it looks to me that libFLAC decoder already
> supports sample rates as 20-bit numbers in the STREAMINFO metadata
> block so up to 1,048,575 Hz if a trick is done by having in
> FRAME_HEADER of each frame the sample rate as "0000 : get from
> STREAMINFO metadata block". If explicitly given in the frame header,
> the maximum sample rate is 655350 Hz.
>
> However, the libFLAC encoder produces an error for sample rates higher
> than 655350 Hz and does not do the above kind of trickery to get
> higher sample rates. Potentially you could modify the encoder and the
> result would still work with an existing decoder. But that would not
> work so well anymore for starting in the middle of a FLAC stream
> without having encountered a STREAMINFO metadata block -- dunno when
> that might happen.

Thanks very much for the suggestion.

Unfortunately using the 'hint' field in METADATA_BLOCK_STREAMINFO to
describe the sample rate as a 20 bit field seems not to be possible as
the documentation clearly stipulates why it's limited to 655350Hz as
"Though 20 bits are available, the maximum sample rate is limited by
the structure of frame headers to 655350Hz." I'm not sure if this is
due to max blocksize being limited to 65535, but either way it doesn't
look like the format in its current form will easily accommodate
arbitrary larger values. If a change is made to support higher than
655350 it should support arbitrary values of any size, perhaps by
allowing a bigger multiplier in the header than 10x. I'll dig around
myself but it seems in its current form the container would not cope.

Thanks,
Con

>
> -olli (I am not a FLAC developer)
>
> On Tue, Jun 2, 2020 at 6:59 AM Con Kolivas <kernel at kolivas.org> wrote:
> >
> > Hi.
> >
> > I was wondering if there was any interest in extending the flac
> > container format to support sample rates above the 655k current limit.
> > Please note this is not for using ridiculously high sample rate
> > sourced audio for some imaginary audible benefit. I've been involved
> > in some experimentation with offline upsampling in software prior to
> > delivery to an external DAC as a way to bypass the DAC's internal
> > oversampling and found that wavpak is the only compressed container
> > format that supports the 705/768 sample rates but it is very poorly
> > supported and extremely slow during decompression, and fully
> > uncompressed WAV data is extremely cumbersome. Most DACs do appear to
> > turn off their anti-aliasing filters at sample rates above 192kHz so
> > 384 may well be the limit of any theoretical benefit, but many DACs
> > now support input up to 768kHz (a very small number support even
> > higher.) Studio ADCs often record in the Mhz range, and although they
> > apparently always decimate as they sample, there may be a theoretical
> > use for the data as is. It would be nice if the flac container was
> > extensible to any arbitrary value for research purposes.
> >
> > Thanks,
> > -ck
> > _______________________________________________
> > flac-dev mailing list
> > flac-dev at xiph.org
> > http://lists.xiph.org/mailman/listinfo/flac-dev