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>
On Fri, 26 Jun 2020 at 00:37, Martijn van Beurden <mvanb1 at gmail.com> wrote:> > 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.Definitely not a lab setting I'm afraid, I'm just experimenting at home with my regular hi-fi gear. I'm just using clementine and roon for playback and both load libFLAC so I guess I could create a custom flac library to support a bastardised flac container. Thanks, Con
Progress. A simple hack to allow bitrates above 655350 seemed to work fine for encoding, and the standard reference decoder library decoded it fine. I'm not sure then in the documentation why it says "the maximum sample rate is limited by the structure of frame headers to 655350Hz". Perhaps this breaks something elsewhere but the attached simple patch is working perfectly fine for my use case here! Can anyone see a reason this might break something elsewhere and couldn't be incorporated? Thanks, Con On Fri, 26 Jun 2020 at 08:33, Con Kolivas <kernel at kolivas.org> wrote:> > On Fri, 26 Jun 2020 at 00:37, Martijn van Beurden <mvanb1 at gmail.com> wrote: > > > > 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. > > Definitely not a lab setting I'm afraid, I'm just experimenting at > home with my regular hi-fi gear. I'm just using clementine and roon > for playback and both load libFLAC so I guess I could create a custom > flac library to support a bastardised flac container. > > Thanks, > Con-------------- next part -------------- A non-text attachment was scrubbed... Name: highres.patch Type: text/x-patch Size: 2403 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20200626/a6f5d819/attachment-0001.bin>