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
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. -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
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
Op di 2 jun. 2020 om 05:59 schreef Con Kolivas <kernel at kolivas.org>:> It would be nice if the flac container was > extensible to any arbitrary value for research purposes. >Probably not the answer that you were hoping for, but because it is only for research purposes, why not store the samplerate outside of the container, or in the comments as metadata? The FLAC encoder doesn't care what samplerate your material is, it just stores it for easy playback. You can store 10MHz information, tell the FLAC encoder it is 48kHz, and add a tag samplerate=10000000 or even samplerate=10MHz, whatever your processing scripts accept. As you are clearly using FLAC for something it wasn't made for, that doesn't seem like a very big workaround to me? Kind regards, Martijn van Beurden -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20200625/74991c01/attachment.html>
Isn't the FLAC encoder 'tuned' for the compression of audio data at common sample rates anyway? Does it make sense to use FLAC to compress arbitrary analog data at very high sample rates as opposed to other general purpose compression algorithms? Tor Am 25.06.2020 um 14:49 schrieb Martijn van Beurden:> Op di 2 jun. 2020 om 05:59 schreef Con Kolivas <kernel at kolivas.org > <mailto:kernel at kolivas.org>>: > > It would be nice if the flac container was > extensible to any arbitrary value for research purposes. > > > Probably not the answer that you were hoping for, but because it is > only for research purposes, why not store the samplerate outside of > the container, or in the comments as metadata? The FLAC encoder > doesn't care what samplerate your material is, it just stores it for > easy playback. You can store 10MHz information, tell the FLAC encoder > it is 48kHz, and add a tag samplerate=10000000 or even > samplerate=10MHz, whatever your processing scripts accept. > > As you are clearly using FLAC for something it wasn't made for, that > doesn't seem like a very big workaround to me? > > Kind regards, > > Martijn van Beurden > > _______________________________________________ > flac-dev mailing list > flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20200625/f9883c62/attachment.html>