Miroslav Lichvar wrote:
> Will be this patch included in the upcoming release? Or does it need
> more work before it can be accepted?
The patch does not currently apply against git HEAD.
If you or someone ports it to apply cleanly to HEAD I don't see
any reason why it won't be applied.
Cheers,
On Fri, May 04, 2012 at 06:09:06PM +0200, Miroslav Lichvar wrote:
> On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote:
> > The most interesting part of the patch is the rewrite of the
> > FLAC__bitreader_read_rice_signed_block function, which in the git repo
> > seems to have only co
On Mon, May 07, 2012 at 02:18:15PM -0400, Cristian Rodríguez wrote:
> BTW, just wondering, how are you measuring the speed in this tests ?
> I would be interested to know so I can reproduce it here with
> different compile/link options
Running several times "time flac -s -t *.flac" (or flac/.libs/
El 07/05/12 13:37, Miroslav Lichvar escribió:
> On Mon, May 07, 2012 at 09:19:52PM +0400, LRN wrote:
>>> In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with
>>> nasm enabled is about 7% faster in decoding than without nasm.
>>> x86_64 build is about 2% faster than the i686 build with
On Mon, May 07, 2012 at 09:19:52PM +0400, LRN wrote:
> > In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with
> > nasm enabled is about 7% faster in decoding than without nasm.
> > x86_64 build is about 2% faster than the i686 build with nasm
> > enabled.
> >
> Was that with -O2 or
El 07/05/12 09:11, Miroslav Lichvar escribió:
> On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodríguez wrote:
>> El 03/05/12 12:19, Miroslav Lichvar escribió:
>>
>>
>>> It makes the C function faster than the corresponding asm routine, so
>>> if it's included I'd suggest to just drop the asm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07.05.2012 17:11, Miroslav Lichvar wrote:
> On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodríguez
> wrote:
>> El 03/05/12 12:19, Miroslav Lichvar escribió:
>>
>>
>>> It makes the C function faster than the corresponding asm
>>> routine, so
On May 7, 2012, at 06:11, Miroslav Lichvar wrote:
> On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodríguez wrote:
>> El 03/05/12 12:19, Miroslav Lichvar escribió:
>>> It makes the C function faster than the corresponding asm
>>> routine, so
>>> if it's included I'd suggest to just drop the
On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodríguez wrote:
> El 03/05/12 12:19, Miroslav Lichvar escribió:
>
>
> > It makes the C function faster than the corresponding asm routine, so
> > if it's included I'd suggest to just drop the asm function to not keep
> > around more asm code tha
>From: Miroslav Lichvar
>Sent: Friday, May 4, 2012 9:09 AM
>
>On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote:
>> The most interesting part of the patch is the rewrite of the
>> FLAC__bitreader_read_rice_signed_block function, which in the git repo
>> seems to have only couple l
El 04/05/12 12:09, Miroslav Lichvar escribió:
> On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote:
>> The most interesting part of the patch is the rewrite of the
>> FLAC__bitreader_read_rice_signed_block function, which in the git repo
>> seems to have only couple lines changed sinc
El 04/05/12 11:53, Miroslav Lichvar escribió:
> On Fri, May 04, 2012 at 11:13:05AM -0400, Cristian Rodríguez wrote:
>> Both Erick and I did already submitted patches to the tree that do just
>> exactly what your flac-1.2.1-bitreader.patch intended.. please checkout
>> current GIT tree.
>
> The most
On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote:
> The most interesting part of the patch is the rewrite of the
> FLAC__bitreader_read_rice_signed_block function, which in the git repo
> seems to have only couple lines changed since 1.2.1.
Here is that part of the patch rebased ag
On Fri, May 04, 2012 at 11:13:05AM -0400, Cristian Rodríguez wrote:
> Both Erick and I did already submitted patches to the tree that do just
> exactly what your flac-1.2.1-bitreader.patch intended.. please checkout
> current GIT tree.
The most interesting part of the patch is the rewrite of the
El 03/05/12 12:19, Miroslav Lichvar escribió:
> It makes the C function faster than the corresponding asm routine, so
> if it's included I'd suggest to just drop the asm function to not keep
> around more asm code than is necessary.
With current compilers it is very likely that those routines ar
El 03/05/12 12:19, Miroslav Lichvar escribió:
> Hi Josh,
>
> nice to see you here again.
>
> On Wed, Apr 25, 2012 at 04:26:05PM -0700, Josh Coalson wrote:
>> (Jumping in again, maybe at the wrong point since this doesn't seem
>> to involve encoding, but here goes.)
>>
>> Miroslav's patches have alw
Hi Josh,
nice to see you here again.
On Wed, Apr 25, 2012 at 04:26:05PM -0700, Josh Coalson wrote:
> (Jumping in again, maybe at the wrong point since this doesn't seem
> to involve encoding, but here goes.)
>
> Miroslav's patches have always been high-quality for sure. But
> regardless of subm
Op 26-04-12 10:27, Ben Allison schreef:
> I've seen this before with, e.g. x264, where a bug is repeated in the encoder
> and decoder and hence not caught by any tests.
So, would it be useful to include some of tests run by another (or
several other) decoder(s)? Probably an older FLAC release of
On 12-04-25 5:11 PM, Josh Coalson wrote:
> Part of the reason the current test suite is so long is to try and discover
> those problems automatically. But it's not possible to be exhaustive
> simply because new code may not be covered by the test suite.
Coverage of the test suite is something th
49 AM, Erik de Castro Lopo wrote:
> Josh Coalson wrote:
>
>> From: Erik de Castro Lopo
>>> To: flac-dev@xiph.org
>>> Cc: Josh Coalson
>>> Sent: Wednesday, April 25, 2012 4:42 PM
>>> Subject: Re: [flac-dev] [Flac-dev] Git branch with
Josh Coalson wrote:
> From: Erik de Castro Lopo
> >To: flac-dev@xiph.org
> >Cc: Josh Coalson
> >Sent: Wednesday, April 25, 2012 4:42 PM
> >Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
> >
> >Josh Coalson wrote:
> >
From: Erik de Castro Lopo
>To: flac-dev@xiph.org
>Cc: Josh Coalson
>Sent: Wednesday, April 25, 2012 4:42 PM
>Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
>
>Josh Coalson wrote:
>
>> But regardless of submitter, any patch th
Josh Coalson wrote:
> But regardless of submitter, any patch that affects encoding must be
> reviewed very carefully, preferably by several other people and definitely
> me.
Is there any way of encoding this manual review process in the test suite
so that people hacking on FLAC can immediately se
nt: Friday, February 10, 2012 1:39 AM
>Subject: Re: [flac-dev] [Flac-dev] Git branch with compiling fixes for win32
>
>Miroslav Lichvar wrote:
>
>> I'd like to see the following patch included. It's not trivial, but I
>> think it's very well tested after those yea
Miroslav Lichvar wrote:
> I'd like to see the following patch included. It's not trivial, but I
> think it's very well tested after those years.
> http://www.mail-archive.com/flac-dev@xiph.org/msg00914.html
>
> An updated version of the patch which includes some other
> optimizations is here.
> h
JonY wrote:
> OK, rebuilt with latest master, no more printf warnings. Here's another
> attached patch to suppress redefinition warnings with mingw-w64 lfs64
> support.
Applied. Thanks.
Erik
--
--
Erik de Castro Lopo
http://www
On 2/3/2012 06:33, JonY wrote:
> On 2/3/2012 02:50, Erik de Castro Lopo wrote:
>> JonY wrote:
>>
>>> Attached patch builds without any warnings for MinGW.
>>
>> Sorry JonY, that patch does not apply against current git master
>> which is here:
>>
>> https://git.xiph.org/?p=flac.git;a=summary
>>
On 2/3/2012 02:50, Erik de Castro Lopo wrote:
> JonY wrote:
>
>> Attached patch builds without any warnings for MinGW.
>
> Sorry JonY, that patch does not apply against current git master
> which is here:
>
> https://git.xiph.org/?p=flac.git;a=summary
>
> Specifically I pulled out much of t
JonY wrote:
> Attached patch builds without any warnings for MinGW.
Sorry JonY, that patch does not apply against current git master
which is here:
https://git.xiph.org/?p=flac.git;a=summary
Specifically I pulled out much of the "#ifdef _MSC_VER" printf stuff
in this commit:
https://g
On 2/1/2012 22:36, JonY wrote:
> On 2/1/2012 18:52, Erik de Castro Lopo wrote:
>> JonY wrote:
>>
>>> Alright, here's a quick fix, although it is more ugly than I remembered.
>>>
>>> Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
>>> where available, and falls back to I64 on M
JonY wrote:
> > Sorry for the delay on actually getting on to this.
> >
> > I tried your patch, but it wasn't quite right. The problem is that %ll
> > is the correct format specifier for uint64_t on 32bit Linux but not
> > on 64 bit Linux.
> >
>
> Something is very very wrong about the above st
On 2/1/2012 18:52, Erik de Castro Lopo wrote:
> JonY wrote:
>
>> Alright, here's a quick fix, although it is more ugly than I remembered.
>>
>> Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
>> where available, and falls back to I64 on MSVC and then ll for others,
>> all for
LRN wrote:
> Is it wise to aim at C99? While i have absolutely nothing against it,
> it is a known fact that MS never got around to support C99 in MSVC to
> any considerable degree.
The idea is to only use the bits of C99 that can be worked around in
MSVC with #ifdefs and #defines.
Erik
--
Bastiaan Timmer wrote:
> Well, I have been away a couple of days, so I don't know if I'm in time, but
> I reported a memory leak and submitted a patch a couple of months ago. It
> would be nice if it can make it in.
>
> I first reported the leak here:
> http://lists.xiph.org/pipermail/flac-dev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01.02.2012 14:52, Erik de Castro Lopo wrote:
> In C99, the correct way to print a uint64_t value is:
>
Is it wise to aim at C99? While i have absolutely nothing against it,
it is a known fact that MS never got around to support C99 in MSVC to
any
JonY wrote:
> Alright, here's a quick fix, although it is more ugly than I remembered.
>
> Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h
> where available, and falls back to I64 on MSVC and then ll for others,
> all format warnings suppressed.
JonY,
Sorry for the delay o
On 12/06/2011 08:44 AM, Erik de Castro Lopo wrote:
> Sven-Hendrik Haase wrote:
>
>> Sooo any news?
> Unfortunately, my day job, my family and a bunch of other commitments
> have been getting in my way.
>
> I *know* I will have some free time between xmas and new year. I have
> no guarantees of any
Sven-Hendrik Haase wrote:
> Sooo any news?
Unfortunately, my day job, my family and a bunch of other commitments
have been getting in my way.
I *know* I will have some free time between xmas and new year. I have
no guarantees of any decent block of time showing up before that.
Erik
--
On 11/16/2011 07:47 PM, Erik de Castro Lopo wrote:
> Avuton Olrich wrote:
>
>> Hello,
>>
>> Hate to be Capt. obvious here, but there's a lot of development going
>> on here that should be encouraged. If the FLAC project isn't going to
>> open up, it would make a lot of sense for someone to take ove
JonY wrote:
> > Wow ok, haven't touched it since the gnone2 days, it was pretty decent
> > back then.
> >
> > I'll come back later then.
> >
>
> Ping, anything new?
Well I've replaced Gnome3 with XMonad which is a huse step in the
right direction. Still super busy with a bunch of other things
On 11/16/2011 06:49, JonY wrote:
> On 11/16/2011 03:20, Erik de Castro Lopo wrote:
>> JonY wrote:
>>
>>> On 11/14/2011 18:01, JonY wrote:
On 11/10/2011 19:22, JonY wrote:
> On 11/10/2011 18:39, Erik de Castro Lopo wrote:
>>
>> I'm subscribed to the list (and I set my reply-to to th
On Wed, Nov 16, 2011 at 03:36:12PM -0800, bri...@sounds.wa.com wrote:
> > This will leave Apple with even less reasons to support FLAC ...
>
> You make some important observations, but I do not see how anything
> can be done by the FLAC team about Apple's lack of support.
I think that only peo
On Thu, Nov 10, 2011 at 09:58:03AM +1100, Erik de Castro Lopo wrote:
> If anyone else has Flac patches that they would like to
> see commited to the Xiph Git repo, now would be a good time
> to speak up.
I'd like to see the following patch included. It's not trivial, but I
think it's very well tes
es to fix them (after reviewing the patch of course).
--- On Sat, 11/19/11, Brian Willoughby wrote:
> From: Brian Willoughby
> Subject: Re: [Flac-dev] Git branch with compiling fixes for win32
> To: "Bastiaan Timmer"
> Cc: flac-dev@xiph.org
> Date: Saturday, November 19, 2
What bugs?
On Nov 18, 2011, at 04:16, Bastiaan Timmer wrote:
> It's good to see some updates to the FLAC project after so much
> time! Will there be any timeline for a bugfix-release?
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/
's good to see some updates to the FLAC project after so much time! Will
there be any timeline for a bugfix-release?
thanks,
Bas Timmer
--- On Wed, 11/9/11, Erik de Castro Lopo wrote:
> From: Erik de Castro Lopo
> Subject: Re: [Flac-dev] Git branch with compiling fixes for win32
>
On Nov 16, 2011, at 14:11, Declan Kelly wrote:
> On Wed, Nov 16, 2011 at 05:41:21AM -0800, avu...@gmail.com wrote:
>> Hate to be Capt. obvious here, but there's a lot of development going
>> on here that should be encouraged. If the FLAC project isn't going to
>> open up, it would make a lot of se
On Wed, Nov 16, 2011 at 05:41:21AM -0800, avu...@gmail.com wrote:
> Hate to be Capt. obvious here, but there's a lot of development going
> on here that should be encouraged. If the FLAC project isn't going to
> open up, it would make a lot of sense for someone to take over
> maintenance on a gith
Avuton Olrich wrote:
> Hello,
>
> Hate to be Capt. obvious here, but there's a lot of development going
> on here that should be encouraged. If the FLAC project isn't going to
> open up, it would make a lot of sense for someone to take over
> maintenance on a github account with the git-cvsimport
Hello,
Hate to be Capt. obvious here, but there's a lot of development going
on here that should be encouraged. If the FLAC project isn't going to
open up, it would make a lot of sense for someone to take over
maintenance on a github account with the git-cvsimport or such. I
don't see anyone stepp
On 11/09/11 02:58 pm, Erik de Castro Lopo wrote:
If anyone else has Flac patches that they would like to
see commited to the Xiph Git repo, now would be a good time
to speak up.
A couple of build system fixes for OS/2. Not very experienced with git
so just attaching.
Dave
From e47dc34e2025cf0
On 11/16/2011 03:20, Erik de Castro Lopo wrote:
> JonY wrote:
>
>> On 11/14/2011 18:01, JonY wrote:
>>> On 11/10/2011 19:22, JonY wrote:
On 11/10/2011 18:39, Erik de Castro Lopo wrote:
>
> I'm subscribed to the list (and I set my reply-to to the list).
> Please do not CC me.
>
JonY wrote:
> On 11/14/2011 18:01, JonY wrote:
> > On 11/10/2011 19:22, JonY wrote:
> >> On 11/10/2011 18:39, Erik de Castro Lopo wrote:
> >>>
> >>> I'm subscribed to the list (and I set my reply-to to the list).
> >>> Please do not CC me.
> >>>
> >>> JonY wrote:
> >>>
> Its probably on one o
On 11/14/2011 18:01, JonY wrote:
> On 11/10/2011 19:22, JonY wrote:
>> On 11/10/2011 18:39, Erik de Castro Lopo wrote:
>>>
>>> I'm subscribed to the list (and I set my reply-to to the list).
>>> Please do not CC me.
>>>
>>> JonY wrote:
>>>
Its probably on one of the sf tracker somewhere, I can
On 11/10/2011 19:22, JonY wrote:
> On 11/10/2011 18:39, Erik de Castro Lopo wrote:
>>
>> I'm subscribed to the list (and I set my reply-to to the list).
>> Please do not CC me.
>>
>> JonY wrote:
>>
>>> Its probably on one of the sf tracker somewhere, I can't seem to find it
>>> anymore. It wasn't a
>
> Development is probably complete. Maintenance should continue.
Speaking of which, I plan on starting AMD64, ARMv5, and ARMv7 assembly
routines in the next few weeks. I'll sync up with Erik on getting them
integrated.
-Ben Allison
___
Flac-dev maili
On 11/10/2011 18:39, Erik de Castro Lopo wrote:
>
> I'm subscribed to the list (and I set my reply-to to the list).
> Please do not CC me.
>
> JonY wrote:
>
>> Its probably on one of the sf tracker somewhere, I can't seem to find it
>> anymore. It wasn't anything complicated, so I should be able
I'm subscribed to the list (and I set my reply-to to the list).
Please do not CC me.
JonY wrote:
> Its probably on one of the sf tracker somewhere, I can't seem to find it
> anymore. It wasn't anything complicated, so I should be able to redo it
> quickly.
I'm a Linux guy. I do not have easy ac
On 11/10/2011 18:13, Sean M. Pappalardo - D.J. Pegasus wrote:
> Not sure if the patches you already have address this, but here are some
> hacks I collected to try to get libFLAC to build on Windows for Mixxx:
> http://mixxx.org/wiki/doku.php/build_windows_dependencies#libflac
>
> I have never a
Not sure if the patches you already have address this, but here are some
hacks I collected to try to get libFLAC to build on Windows for Mixxx:
http://mixxx.org/wiki/doku.php/build_windows_dependencies#libflac
I have never actually gotten it to build on x64 and right now just use
OpenCodecs' di
On 11/10/2011 08:02, Erik de Castro Lopo wrote:
> JonY wrote:
>
>> I submitted a patch sometime ago to correct printf specifiers for win32
>> by using inttypes.h, but there were no response, so I thought flac
>> development was dead.
>
> Development is probably complete. Maintenance should contin
JonY wrote:
> I submitted a patch sometime ago to correct printf specifiers for win32
> by using inttypes.h, but there were no response, so I thought flac
> development was dead.
Development is probably complete. Maintenance should continue.
> Not sure where the patch went or if its still valid.
On 11/10/2011 06:58, Erik de Castro Lopo wrote:
> Sven-Hendrik Haase wrote:
>
>> Si señor: http://code.entropywave.com/git/flac.git
>
> Ok, there are about 6 commits there. Over the weekend I'll
> have a look at them and if they're fine, I'll push them to
> the Xiph Git repo.
>
> If anyone else
Sven-Hendrik Haase wrote:
> Si señor: http://code.entropywave.com/git/flac.git
Ok, there are about 6 commits there. Over the weekend I'll
have a look at them and if they're fine, I'll push them to
the Xiph Git repo.
If anyone else has Flac patches that they would like to
see commited to the Xiph
Erik de Castro Lopo wrote:
>Sven-Hendrik Haase wrote:
>
>> I found this git repo that contains fixes for mingw32 compilation of
>> flac: git://code.entropywave.com/git/flac.git
>> Switch to the "ew" branch to see the fixes. I'd be glad if this went
>> upstream as it'd make my job easier.
>
>Is
Sven-Hendrik Haase wrote:
> I found this git repo that contains fixes for mingw32 compilation of
> flac: git://code.entropywave.com/git/flac.git
> Switch to the "ew" branch to see the fixes. I'd be glad if this went
> upstream as it'd make my job easier.
Is there a gitweb interface to this?
Ch
I found this git repo that contains fixes for mingw32 compilation of
flac: git://code.entropywave.com/git/flac.git
Switch to the "ew" branch to see the fixes. I'd be glad if this went
upstream as it'd make my job easier.
___
Flac-dev mailing list
Flac-d
67 matches
Mail list logo
