Re: [flac-dev] Build systems to keep
As a windows/visual studio user, I agree. CMake is a solid alternative for building flac. Thanks for supporting Windows! Jim On Sun, May 1, 2022 11:22 am, Martijn van Beurden wrote: > Hi all, > > > Currently flac has 4 build systems: autotools (configure.ac), CMake, > Makefile.lite and Visual Studio files. I think this is too much and > like some opinions on which to remove. > > I propose to remove the Visual Studio files (a mention has already > been put in the changelog and README of the 1.3.4 release that they will be > removed) because that was already planned. CMake takes over the role of > providing a build system for Visual Studio. As recent releases of Visual > Studio actually feature integration of CMake, one > could see CMake as being 'endorsed' by Microsoft. Visual Studio users will > get a better maintained and configurable build system instead of the rigid > files flac provides right now. > > I'd also like to remove the Makefile.lite build system. From a remark > in the README it seems it was at some point created to provide an > alternative or back-up for the autotools build system, but a much more > flexible alternative is now available: CMake. > > I'd like to hear your thoughts on this matter. > > > Kind regards, > > > Martijn van Beurden > ___ > flac-dev mailing list flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] 64-bit residuals
Hi Martijn, I just want to thank you for your thoughtful attention to these details. Much appreciated! Jim On Thu, March 24, 2022 9:05 am, Martijn van Beurden wrote: > Hi all, > > > I just filed an issue on github: > https://github.com/xiph/flac/issues/306 Long story short: libFLAC > currently uses 32-bit signed integers for residuals, but using certain > 24-bit (crafted) material can overflow this. For examples and an > explanation see the github issue. > > I'm sending this e-mail because I'd like to attract some extra > attention towards it. I'm working on patching this, but the residual is > actually exported through the API (as part of the subframe) so I'd like to > have some discussion on what would be the best way to fix this. I see the > following options: > > 1) Change all residual handling from 32-bit int to 64-bit int. This > might incur a performance penalty and it might invalidate certain > approaches now used with intrinsics. It also presents an API change 2) > Change the current 32-bit signed integer arrays which are used for > residual handling to a union within a struct. This union would hold both a > 32-bit int and a 64-bit int variant of the residual, and the > struct would include a bool to clarify which of the two is being used. For > each function manipulating residuals (bitreader, bitwriter, lpc restore > etc.) a new _ultrawide variant is written and at several places in the > code a decision has to be added whether to use the _ultrawide variant or > the existing ones. This changes the API a little more, but makes it able > to keep the current intrinsics accelerated functions 3) Add a note to the > FLAC spec that residuals should not exceed > 32-bit, and add a mechanism to the encoder to ascertain this. In case > the encoder finds a residual exceeding the 32-bit range, it defaults to > using a verbatim subframe. > > Any thoughts? > ___ > flac-dev mailing list flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] IETF FLAC specification
I don't know Josh, but apparently, this is his LinkedIn profile: https://www.linkedin.com/in/josh-coalson-9933548b/ Jim On Tue, October 26, 2021 11:57 pm, Martijn van Beurden wrote: > Hi all, > > > A few years ago, the Codec Encoding for LossLess Archiving and > Realtime transmission (CELLAR) working group of the IETF was formed. > They have been working on expanding current open standards, including > Matroska, EBML, FFV1 and FLAC with the aim of publishing RFCs for > these formats. > > The thing is, they started out with the 'Format' document that is on > the website, which is licensed under GFDL. This document (according to git > history) has barely been touched by anyone since Josh Coalson disappeared > from the FLAC project. Due to legal issues at the IETF, the question was > asked if Josh Coalson could be contacted about exempting the IETF of the > requirements the GFDL poses. Apparently, the IETF would like to reserve > the right to call something RFC , and not have someone else edit the > document and publish it as an IETF RFC. This is covered by trademark > rights in most, but not all countries, which is why the IETF doesn't want > to use GNU FDL protected parts. > > So, CELLAR has two options: rewrite the whole document or contact Josh > Coalson on this issue. My question now is: does anyone know how to > contact him? Can perhaps someone forward this e-mail or contact him > directly? > > Kind regards, > > > Martijn van Beurden > ___ > flac-dev mailing list flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
