. I tried your code with some
16-bit audio expanded with 16 bits of noise and I don't see a large
difference here either.
Thanks for you work on this.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
uals, I
suspect that would have a significant impact, so I'm wondering how it
is different with 32-bit audio.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
On Tue, Mar 29, 2022 at 04:57:10PM +0200, Martijn van Beurden wrote:
> Op di 29 mrt. 2022 om 11:43 schreef Miroslav Lichvar :
> > The third option makes most sense to me. I don't think we should
> > complicate decoders by requiring them to support 64-bit residuals only
> > bec
stream as invalid, but they
should not crash.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
d to be reasonably sure it really is a FLAC
frame.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
On Wed, Jul 18, 2018 at 12:30:41PM +0200, Miroslav Lichvar wrote:
> Should safe_realloc_add_2op_() be
> changed to use safe_realloc_() instead of realloc()? Is there any code
> in flac that relies on the current behavior?
It does indeed look like some code that (indirectly) uses the
safe
---
include/share/alloc.h | 36 +---
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/include/share/alloc.h b/include/share/alloc.h
index 63878db0..97752f0c 100644
--- a/include/share/alloc.h
+++ b/include/share/alloc.h
@@ -174,34 +174,46 @@ static
---
include/share/alloc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/share/alloc.h b/include/share/alloc.h
index 914de9ba..63878db0 100644
--- a/include/share/alloc.h
+++ b/include/share/alloc.h
@@ -168,7 +168,7 @@ static inline void *safe_realloc_add_2op_(void
When safe_realloc_add_2op_(utfbuf, ...) is called with an invalid size
and returns 0, set utfbuf to 0 to avoid second deallocation later in the
function.
---
src/share/utf8/iconvert.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/share/utf8/iconvert.c
that relies on the current behavior?
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
.
> > * If there is an statistically measurable performance, keep it, otherwise
> > remove the FLAC__BYTES_PER_WORD == 8 code all together.
>
> I'll try to do it, but I don't have a deep understanding of bit(read|write)
> routines such as FLAC__bitreader_read_rice_signed_bloc
.
Yeah, the current code looks right to me. I think we already discussed
this some time ago. I'd just remove that comment.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
On Thu, Dec 11, 2014 at 04:50:24PM +0100, Martijn van Beurden wrote:
2014-12-11 14:34 GMT+01:00 Miroslav Lichvar mlich...@redhat.com:
So the problem is that FLAC__stream_decoder_process_single returns
error before it finds a valid frame?
I'm not sure whether we mean the same thing, but I
To avoid crash caused by an unbound LPC decoding when predictor order is
larger than blocksize, the sanity check needs to be moved to the subframe
decoding functions.
---
src/libFLAC/stream_decoder.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff
On Tue, Nov 25, 2014 at 11:40:37AM -0800, Erik de Castro Lopo wrote:
Miroslav Lichvar wrote:
I think the case with non-zero partition order may need to be fixed
too. For example, with partition order of 1, predictor order of 16 and
blocksize of 4, the function would return true
:
In this case the minimum amount of data that the attacker can write to
the buffer seems to be nearly 16GB (4 * (INT_MAX - 31)), so I think most
libFLAC applications will just crash. But I could very well be missing
something.
--
Miroslav Lichvar
___
flac-dev
On Wed, Nov 26, 2014 at 06:09:38PM +0300, lvqcl wrote:
There's an entry in the changelog:
Improved decoding efficiency of all bit depths but especially so for 24 bits
(lvqcl)
A couple of comments:
1) The patch that improves encoding for all depths was proposed by Miroslav
Lichvar
=
FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC;
- return true;
+ return false;
}
}
Thoughts?
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
will have to be made anyway to not force
the users to the vulnerable version.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
.
Well, this reverts the commit 18e0154. How is the user supposed to set
CFLAGS without getting -O3 -funroll-loops there? (e.g. to minimize the
size of the compiled binaries)
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http
On Tue, Jul 29, 2014 at 07:47:33PM +1000, Erik de Castro Lopo wrote:
Miroslav Lichvar wrote:
Well, this reverts the commit 18e0154. How is the user supposed to set
CFLAGS without getting -O3 -funroll-loops there? (e.g. to minimize the
size of the compiled binaries)
Is it -O3
*
when encoding with preset -8 between FLAC 1.3.0 and current git.
That's indeed a significant improvement. I'm assuming most of it is
from the SSE intrinsic code. Good job, lvqcl!
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http
on
non-ppc archs, but in this case I think it doesn't really matter. It
would make the code less readable and more likely someone will forgot
about it in the future and break it for ppc.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http
On Mon, Jun 30, 2014 at 08:08:42PM +1000, Erik de Castro Lopo wrote:
Can someone please provide me with a copy of the file snippet6.wav ? I'd
like to test this some more.
I got it from
http://wootangent.net/~lsd/blah/snippet6.wav
--
Miroslav Lichvar
, there is no
multiplication, so it shouldn't be a problem.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
in the file that Erik is the current
maintainer. :)
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
On Fri, Jun 20, 2014 at 01:21:03PM +0400, lvqcl wrote:
Miroslav Lichvar цкщеу:
+/*
+ * This is used to avoid overflow with unusual signals in 32-bit
+ * accumulator in the *precompute_partition_info_sums_* functions.
+ */
+#define FLAC__MAX_EXTRA_RESIDUAL_BPS 4
On Fri, Jun 20, 2014 at 02:15:31PM +0400, lvqcl wrote:
Miroslav Lichvar wrote:
As overflow in the accumulator won't result in a data loss, I think
this is good enough until someone can figure out a better approach.
FLAC calculates real bitdepth of input signal for every block
On Thu, Jun 19, 2014 at 07:28:11PM +1000, Erik de Castro Lopo wrote:
Miroslav Lichvar wrote:
In file included from /usr/include/math.h:45:0,
from grabbag/replaygain.c:25:
/usr/include/bits/mathdef.h:35:21: note: previous declaration of 'float_t'
was here
typedef long
In the precompute_partition_info_sums_ function, instead of selecting
64-bit accumulator when the signal bps is larger than 16, revert to the
original approach based on partition size, but make room for few extra
bits to not overflow with unusual signals where the average residual
magnitude may be
stream? Based on the
analysis above, the currently used check allows residuals at most 1
bit wider than bps. Another problem could be that the
local_lpc_restore_signal_16bit function may truncate the residual to
16 bits.
--
Miroslav Lichvar
___
flac-dev
On Thu, Jun 19, 2014 at 03:30:06PM +0200, Miroslav Lichvar wrote:
But, as we have seen with unusual data the residual signal can be
wider than bps. The FLAC format specification doesn't seem to mention
this. Should it be treated as a valid FLAC stream?
I think it would be interesting to know
On Thu, Jun 19, 2014 at 05:04:23PM +0200, Miroslav Lichvar wrote:
Yes, it's the same check. Assuming residual can be at most
FLAC__MAX_EXTRA_RESIDUAL_BPS bits wider than subframe_bps, I think it
should be:
if(subframe_bps + qlp_coeff_precision + FLAC__bitmath_ilog2(order
this fix. It will probably hurt performance with 16-bit
data and it won't fix the problem in the assembly code.
I think the check if 32-bit accumulator is enough should be improved
instead if possible.
--
Miroslav Lichvar
___
flac-dev mailing list
flac
Don't use the assembly function since it seems to be slower than
the current version of FLAC__bitreader_read_rice_signed_block.
---
src/libFLAC/stream_decoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c
index
that assembly function as the C
version seems to be faster now.
Can anyone confirm this?
Thanks,
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
.
Thanks,
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
---
doc/html/documentation_tools_flac.html | 8 +---
doc/html/ru/documentation.html | 2 +-
man/flac.1 | 6 --
man/flac.sgml | 5 +++--
src/flac/main.c| 4 +++-
5 files changed, 16 insertions(+), 9
? It seems
the declarations in the header files don't have inline and they are
included with the definitions, so they shouldn't be inline definitions
and should be callable from other units.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http
for MSVC.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
, then the
definition in that translation unit is an inline definition.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
negatively affect the performance?
Wouldn't it be better to use a logarithmic scale in the graphs for
encoding/decoding times and speeds?
Thanks,
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
On Thu, Dec 27, 2012 at 01:08:04PM -0600, J. Hendricks wrote:
4. The compiler complained when lround() in lpc.c was static, so it is
no longer static.
This seems strange. Was there any explanation why is it needed?
--
Miroslav Lichvar
___
flac-dev
on the directory to be
searched by default, but I think it might be worth mentioning in the
changelog.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Hide all cglobal symbols with nasm = 2.
---
src/libFLAC/ia32/nasm.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/libFLAC/ia32/nasm.h b/src/libFLAC/ia32/nasm.h
index 8455772..e58b744 100644
--- a/src/libFLAC/ia32/nasm.h
+++ b/src/libFLAC/ia32/nasm.h
@@ -57,7 +57,11
With gcc = 4 and ELF, set default visibility to hidden and make visible
only the symbols with FLAC_API or FLACPP_API.
A convenience libFLAC-static.la is created for test_libFLAC as it
depends on the hidden symbols.
---
configure.ac | 8 +++-
include/FLAC++/export.h | 13
---
configure.ac | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 2db9035..f4a31e4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -25,6 +25,8 @@ AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([foreign -Wall tar-pax no-dist-gzip dist-xz
They are not needed since the section is defined in nasm.h.
---
src/libFLAC/ia32/bitreader_asm.nasm | 4
src/libFLAC/ia32/cpu_asm.nasm| 4
src/libFLAC/ia32/fixed_asm.nasm | 4
src/libFLAC/ia32/lpc_asm.nasm| 4
---
man/flac.1| 4
man/flac.sgml | 2 ++
2 files changed, 6 insertions(+)
diff --git a/man/flac.1 b/man/flac.1
index eaeb028..bd112af 100644
--- a/man/flac.1
+++ b/man/flac.1
@@ -310,6 +310,8 @@ Force the decoder to output Wave64 format. This option is
not needed if the out
.TP
{,++}/export.h might need an update too.
Also, will it be called 1.2.2? I'd like to make some prerelease rpm
packages from the current git snapshot.
Thanks for all the work you have put into this.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
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 couple
---
src/libFLAC/include/private/bitmath.h |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/libFLAC/include/private/bitmath.h
b/src/libFLAC/include/private/bitmath.h
index d32b1a7..4e60f78 100644
--- a/src/libFLAC/include/private/bitmath.h
+++
---
src/libFLAC/include/private/bitmath.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/libFLAC/include/private/bitmath.h
b/src/libFLAC/include/private/bitmath.h
index 61b0e03..d32b1a7 100644
--- a/src/libFLAC/include/private/bitmath.h
+++
---
src/libFLAC/bitreader.c | 445 +++
1 files changed, 105 insertions(+), 340 deletions(-)
diff --git a/src/libFLAC/bitreader.c b/src/libFLAC/bitreader.c
index 2660c42..099b703 100644
--- a/src/libFLAC/bitreader.c
+++ b/src/libFLAC/bitreader.c
@@
Reorder the conditions according to the expected distribution of input
signal. This seems to make it almost as fast as the clz builtin using
the bsr instruction.
---
src/libFLAC/bitreader.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/libFLAC/bitreader.c
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 than
with the git version.
Unfortunately I don't recall the details.
On Mon, May 07, 2012 at 01:23:03PM -0400, Cristian Rodríguez wrote:
Did you build with -fprofile-generate ... then make check .. then
rebuild with -fprofile-use ?
No, I have not tried that.
--
Miroslav Lichvar
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.
BTW, how much faster is the code with the clz builtin? If the
architecture doesn't have the instruction, will be the gcc code as
fast as the original code?
--
Miroslav
On Mon, Mar 17, 2008 at 06:55:01PM +0100, Miroslav Lichvar wrote:
attached are patches that improve decoding speed a bit. The first
patch improves the bit scan macro used for decoding unary values, the
second one adds a GCC inline assembly for bswap and the third patch
replaces
;
FLAC__ASSERT(order 0);
--
Miroslav Lichvar
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
and this operator shifts only to right.
(int)x -1 is the same as (int)x 31.
--
Miroslav Lichvar
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
.
Has anyone else tested on amd64?
Yes, I can confirm it. There is also one missed replacement in
FLAC__BitbufferReadCallback declaration.
--
Miroslav Lichvar
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
loop on
streams with shuffled frames.
--
Miroslav Lichvar
Index: src/libFLAC/stream_decoder.c
===
RCS file: /cvsroot/flac/flac/src/libFLAC/stream_decoder.c,v
retrieving revision 1.117
diff -u -r1.117 stream_decoder.c
--- src/libFLAC
On Fri, Nov 03, 2006 at 10:01:42AM +0100, Miroslav Lichvar wrote:
Thanks. Sending latest version of the patch. Now it can seek in files
that have large id3 tag (or any random data) at the end and it won't loop on
streams with shuffled frames.
One small patch on top of that and it's bug free
also sourceforge bug #1154585
This bug is fixed in CVS already.
--
Miroslav Lichvar
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
10s 53 53 9 9
100s87 9 8 8
- 1 162010 13
Attached is the new patch.
--
Miroslav Lichvar
Index: stream_decoder.c
66 matches
Mail list logo
