Re: [flac-dev] FLAC specification clarification

2020-06-26 Thread Thomas Zander
On Fri, 26 Jun 2020 at 05:15, Brian Willoughby wrote: > That said, there's nothing wrong with adding a note to the specification > about the common implementations, particularly the reference library. Then, > future developers will know both the precise specification and still have the >

Re: [flac-dev] Prelease now available

2019-07-20 Thread Thomas Zander
On Fri, 19 Jul 2019 at 23:35, Erik de Castro Lopo wrote: > > Erik de Castro Lopo wrote: > > > Hopefull the final release candidate: > > > > http://mega-nerd.com/tmp/flac-1.3.3rc3.tar.xz > > http://mega-nerd.com/tmp/flac-1.3.3rc3.tar.xz.asc Builds fine on FreeBSD with clang / LLVM 8.0.0.

Re: [flac-dev] Do we need a pre-release?

2016-12-08 Thread Thomas Zander
On 7 December 2016 at 21:08, Erik de Castro Lopo wrote: > lvqcl.mail wrote: > >> "make -f Makefile.lite" also doesn't work out of box. > > Didn't work for the 1.3.1 release either. Makes me wonder why we even > keep it around. Because it works on many systems with only tiny

Re: [flac-dev] Do we need a pre-release?

2016-12-06 Thread Thomas Zander
On 6 December 2016 at 10:12, Erik de Castro Lopo wrote: > > Subject line says it all. Opinions? I'd say let's have a release candidate. More often than not, some issues turn up due to the exposure to a larger user base and, hence, test cases. Best regards Riggs

Re: [flac-dev] some report on type 3 wav

2016-01-23 Thread Thomas Zander
On 22 January 2016 at 07:09, Erik de Castro Lopo wrote: >> However, as a last attempt, I used Winrar on the original file and to my >> surprise it was compacted to 79 Mb, only about 33% more than the FLAC >> version representing a file with half the data. > > If the orignal

Re: [flac-dev] Lets do a 1.3.2 release

2016-01-09 Thread Thomas Zander
On 8 January 2016 at 11:56, Erik de Castro Lopo wrote: > I think its time for a new release. The current code base is stable > and I've been building it for x86_64/linux, powerpc/linux, armhf/linux, > x86_64/darwin in a Jenkins build bot. Yes, great idea! This is an active

Re: [flac-dev] FLAC__BYTES_PER_WORD==8 test results

2015-12-30 Thread Thomas Zander
On 29 December 2015 at 21:50, lvqcl wrote: > So, does it make sense to #define FLAC__BYTES_PER_WORD (in bitreader.c) > as 4 for 32-bit and as 8 for 64-bit targets? Your tests so far imply this is a sensible default. I'd say go ahead. We can always change it if it turns out

Re: [flac-dev] How to check for 64-bit CPU?

2015-12-30 Thread Thomas Zander
On 29 December 2015 at 08:08, Erik de Castro Lopo wrote: > I would suggest: > >#if SIZEOF_VOIDP == 8 I believe this is not portable. At least on my machine ("4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)") it's not defined. Probably this one

Re: [flac-dev] FLAC__BYTES_PER_WORD==8 test results

2015-12-29 Thread Thomas Zander
On 29 December 2015 at 17:10, lvqcl wrote: > I wrote a patch that enables FLAC__BYTES_PER_WORD==8 in > libFLAC/bitreader.c and libFLAC\bitwriter.c. > The tests were done on an Intel Nehalem CPU, and flac was compiled > with CGG 4.9.x. If you want to share the patch, I am

Re: [flac-dev] How to check for 64-bit CPU?

2015-12-29 Thread Thomas Zander
On 29 December 2015 at 13:33, Rafaël Carré wrote: > On 12/28/2015 08:35 PM, lvqcl wrote: >> In stream_encoder.c there's the following code: >> >> #if defined FLAC__CPU_X86_64 /* and other 64-bit arch, too */ >> if(mean <= 0x8000/512) { /* 512: more or less optimal

Re: [flac-dev] Supporting 32 bit data

2015-09-26 Thread Thomas Zander
On 26 September 2015 at 09:22, Erik de Castro Lopo wrote: > https://sourceforge.net/p/flac/feature-requests/91/ > [...] > Thoughts? The last comment on the page makes a valid point. If companies start to sell 32bit tracks these days, flac may as well start to support