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 
> warning that they risk incompatibility by deviating from the reference 
> implementation.

This sounds reasonable to me. The wording of this note should be very
clear, though.

Thomas
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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. (I tested the build
using Makefile.lite).

Riggs
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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 tweaks (e.g. passing
an env var) without the mess that is GNU autotools.
I use it frequently and always thought of it of an fine asset to have
(which other projects lack).
Would be nice to keep it IMHO.

Best regards
Riggs
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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 32 bit IEEE float file had been normalized so that all
> sample values are between -1.0 and +1.0 then the exponent part of each
> floating point value (8 bits out of 32 bits) would have been identical
> resulting in a very significant opportunity for a data compressor like
> WinRAR to do it's work.

IIRC WinRAR does not use one single general compression algorithm for
all file types but has its own specialised lossless compression
algorithm for wav files. Not quite as good as flac apparently, but
still.

Riggs
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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 project with active development, we
should release every now and then :-)

>   * Upload Windows Zip to sourceforge.net.

Regarding sourceforge ... sorry in case this has been debated and
discussed before, but the dominant social coding platform these days
is github. New potential contributors are much more likely to already
have a GitHub account than SF and contribution via GH is working
really well already. My suggestion is to move issue tracking to GH and
make it clear on the SF project page that issues should be filed on GH
and development/contributions via GH is preferred. Also the wiki on SF
should be dropped since it is not used at all.

Best regards
Riggs
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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 there is a
better option.

Riggs
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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 comes closest:
#define __SIZEOF_POINTER__ 8

Riggs
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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 happy to repeat some testing on
Sandy Bridge and Core2 with clang.

> Average speed increase for FLAC__BYTES_PER_WORD change from 4 to 8:
> [...]

The slower decoding speed for 24 bit content on x86_64 seems
surprising, but minor.
However losing 15% decoding speed on i386 would be very bad.

Riggs
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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 for both 16- 
>> and 24-bit input */
>>   #else
>>   if(mean <= 0x8000/8) { /* 32-bit arch: use 32-bit math if possible 
>> */
>>   #endif
>>
>> A) How to properly check for 64-bit architectures?
>> I can check for "defined FLAC__CPU_X86_64" or "defined _WIN64".
>> Is it possible to use SIZEOF_VOIDP? such as "#if SIZEOF_VOIDP == 8" ?
>
> That would need a special case for Linux x32 which is x86_64 with 32
> bits pointers

... and this probably won't be the last time we'd need to handle special cases.
Do we really need to handle this at all? Entangling CPU-arch-dependent
#ifdefs with input sample size (see "tuned for N-bit input" a few
lines below" seems weird.
IMHO finding the rice parameter should be independent of the cpu arch
unless there is a spectacular benefit by distinguishing.

Best regards
Riggs
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

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 it.
Personally, I'd say the discussion whether music *needs* 32bit
resolution is a different topic :-)

Best regards
Riggs
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev