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 it.
Personally, I'd say
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 for both 16-
>> and
On 29 December 2015 at 17:16, lvqcl wrote:
> I agree that it's a good idea to test the speed of encoding.
> Maybe different code for 32-bit and 64-bit architectures
> is over-optimization.
I completely agree. With today's complicated CPUs it would be
extremely hard if not impossible to formulate
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 happy to repeat some test
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 comes closest:
#define
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 there is a
better opti
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 project with active de
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 32 bit IEEE float file
On 14 March 2016 at 09:02, Erik de Castro Lopo wrote:
> commit a9f84425cfd5d1dbfb564730ca80d0b588cb4f24
> Author: Erik de Castro Lopo
> Date: Mon Mar 14 18:14:31 2016 +1100
>
> libFLAC/cpu.c: Use `sigemptyset` instead of `__sigemptyset`
>
> The former is POSIX while
On 26 June 2016 at 10:17, Erik de Castro Lopo wrote:
> For OS support, I'm not sure. Didn't later version of SSE add new
> registers?
No, SSE instructions operate on XMM0-8 on i386 and XMM0-15 on amd64,
respectively.
Register width was increased to 256 bit with the introduction of AVX
(YMM0-8 on
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
__
On 7 December 2016 at 08:46, Erik de Castro Lopo wrote:
>> http://mega-nerd.com/tmp/flac-1.3.2pre1-win.zip
>> http://mega-nerd.com/tmp/flac-1.3.2pre1.tar.xz
Builds successfully on FreeBSD amd64 and i386.
Best regards
Riggs
___
flac-dev mailing
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 tweaks (e.g. passing
a
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. (
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
> warni
15 matches
Mail list logo
