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>
On Thu, 25 Jun 2020 at 23:11, Tor-Einar Jarnbjo <tor-einar at jarnbjo.name> wrote:> > 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?The idea is to actually use it for playback, not just storage, and nothing else has the nice asymmetrical fast decompression with such effective compression (wavpack supports 705/768 but is woefully slow on decompression and poorly supported). Mostly the sample rates would be multiples of the common 44.1/48 sample rates so I expect compression to be equally good with simple extrapolation to bigger equivalent sized windows. Thanks, Con> > 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>: >> >> 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 > > _______________________________________________ > flac-dev mailing list > flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev
Tor-Einar Jarnbjo <tor-einar at jarnbjo.name> writes:> 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?As a data point on this, the ld-decode project uses FLAC to compress 40MHz samples of LaserDisc RF, which are a combination of FM composite video, FM audio and CD-style EFM digital audio. FLAC gets much better compression ratios than general-purpose compression algorithms (typically about 55% the size of the 10-bit raw input), and has the advantage that you can directly use audio tools for visualising and manipulating samples. -- Adam Sampson <ats at offog.org> <http://offog.org/>
Op do 25 jun. 2020 om 16:02 schreef Con Kolivas <kernel at kolivas.org>:> The idea is to actually use it for playback, not just storage, and > nothing else has the nice asymmetrical fast decompression with such > effective compression (wavpack supports 705/768 but is woefully slow > on decompression and poorly supported). Mostly the sample rates would > be multiples of the common 44.1/48 sample rates so I expect > compression to be equally good with simple extrapolation to bigger > equivalent sized windows. >In what setting are you thinking about playback? If this is a lab setting, creating a small batch script to fetch the samplerate tag and passing it to a playback program like ffplay doesn't seem a very big deal? If you want playback on current existing, available hardware, augmenting the spec is not going to work. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20200625/8e7f17f6/attachment.html>