that. 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
> >
t the 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
o 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 in
---
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 *pt
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 b/src/share/utf8/
flac 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_s
th_ilog2(order) <= 32
>
> So IMHO the comment is incorrect.
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
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 --git
On Thu, Dec 11, 2014 at 04:50:24PM +0100, Martijn van Beurden wrote:
> 2014-12-11 14:34 GMT+01:00 Miroslav Lichvar :
> > 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
On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote:
> Op 11-12-14 om 10:53 schreef Martijn van Beurden:
> > Op 11-12-14 om 10:05 schreef Miroslav Lichvar:
> >> but I'd rather see the real seeking bug fixed instead
> >
> > I think I might have
ate_->output[channel], subframe->warmup,
sizeof(FLAC__int32) * order);
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
cess if
it didn't read any residuals.
If it breaks seeking, it means there is a bug somewhere else. A
reproducer would be useful.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
; FLAC__ASSERT(total_samples > 0);
>
> - error_scale = 0.5 * M_LN2 * M_LN2 / (FLAC__double)total_samples;
> + error_scale = 0.5 / (FLAC__double)total_samples;
Just curious, is there any explanation why this improves the
compression ratio? Is it a bug?
--
Miroslav Lichvar
__
s
enabled also for x86, but the difference between the x86 assembly and
the C function is much smaller.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
at a motivated cracker can do starting
> with a simple heap overflow. See:
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 c
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
decoder->protected_->state =
FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC;
- return true;
+ return false;
}
}
Thoughts?
--
Miroslav Lichvar
___
flac-dev mailing list
fl
some serious bug is
found in 1.3.1, a new release 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
o be safe */
>
> +setvbuf(file, NULL, _IOFBF, 10*1024*1024); /* 10MB output buffer to
> help reduce disk fragmentation */
> +
Hm, does this mean that every process encoding FLAC files will now
need extra 10MB of memory? Is that ok for sma
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
replaced the above with:
>
> CFLAGS="-O3 -funroll-loops -Wall -W -Winline $CFLAGS"
>
> so CFLAGS are preserved and enforce optimisations.
Well, this reverts the commit 18e0154. How is the user supposed to set
CFLAGS without getting -O3 -funroll-loops there? (e.g. to minimi
ps because it's easier to do it in C than in asm? :)
Wrapping the check in #ifdef will save few instructions 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
to 70% speed increase*
> 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 maili
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
--
Miros
might work
for fixed frames, for LPC it looks too pessimistic.
> ...And maybe it's also better to use 'subframe_bps + order' instead of 'order'
> in calculation of 'estimate' variable in evaluate_fixed_subframe_()?
Why exac
est_predictor_wide()
> if "bits_per_sample + FLAC__bitmath_ilog2(blocksize)+1 > 30" is true
> (see encoder->private_->use_wide_by_block variable in stream_encoder.c)
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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
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.
> > + */
> > +#d
be nice to mention 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
y added to the original signal, 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
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_
>
> if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32)
> if(bps <= 16 && subframe->qlp_coeff_precision <= 16)
> decoder->private_->local_lpc_restore_signal_16bit(...);
> else
&
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
al can be
wider than bps. The FLAC format specification doesn't seem to mention
this. Should it be treated as a valid FLAC stream? Based on the
analysis above, the currently used check allows residuals at most 1
bit wider than bps. Another problem c
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
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 &#
here
typedef long double float_t; /* `float' expressions are evaluated as
^
Makefile:613: recipe for target 'grabbag/replaygain.lo' failed
It seems to be related to the recent commit b4f7528e.
--
Miroslav Lichvar
__
On Sun, Jul 21, 2013 at 09:19:46PM +1000, Erik de Castro Lopo wrote:
> Miroslav Lichvar wrote:
> > >
> > > https://git.xiph.org/?p=flac.git;a=commit;h=6f7ec60c7e7f05f5ab0b1cf6b7b0945e44afcd4b
> >
> > I don't like this fix. It will probably hurt perform
afcd4b
I don't like 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
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 f98
as the encoding? Could it be caused by
increase in the size of the function (only with -funroll-loops?) and
not fitting in the cache during encoding?
It might be good to use -funroll-loops only with some files, IIRC it
helped most to stream_encoder.c.
--
Miroslav Lichvar
__
The NUL char is written at incorrect place when the destination string
is longer than 0, which causes memory corruption. It was broken by
commit 2d6354ff2a618a79d40edbd4f208b4b07c5422f1.
---
src/metaflac/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/metaflac/utils
102.7%
I think we should drop 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
o the
optimizations flags, e.g. "-m32 -O3 -funroll-loops" to match the
default CFLAGS.
Thanks,
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
. It should be added to the changelog.
--
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 deletio
ted):
If all of the file scope declarations for a function in a translation
unit include the inline function specifier without extern, 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
etter solutions to fix the problem, I'd suggest to
#define inline to nothing for MSVC.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
on't see the problem. What exactly is the compiler error? 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
_
a 32 or
64-bit system? Doesn't using wine 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@x
how many clients are relying 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
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
__
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
src/libFLAC/ia32/stream_encode
---
include/FLAC++/export.h | 4 ++--
include/FLAC/export.h | 4 ++--
src/libFLAC++/Makefile.am | 2 +-
src/libFLAC/Makefile.am | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/FLAC++/export.h b/include/FLAC++/export.h
index d3bd136..1cb0214 100644
--- a/inclu
---
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 subdir
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
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
ually be
9:0:3. The values in libFLAC{,++}/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
---
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
\fB--
---
man/flac.1| 25 +
man/flac.sgml |2 ++
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/man/flac.1 b/man/flac.1
index fef4ded..3d7bd50 100644
--- a/man/flac.1
+++ b/man/flac.1
@@ -68,6 +68,9 @@ Prefix each output file name with the given string.
---
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
@@ -711
---
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
+++ b/src/libFLAC/include/pri
---
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
+++ b/src/libFLAC/incl
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
> &g
uot; (or flac/.libs/lt-flac
to avoid the libtool wrapper) and picking the shortest real time.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
it seems decoding is a tiny bit faster 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 ?
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 no
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 b/sr
used with just one small library
(freebl3) instead of the whole NSS stack.
--
Miroslav Lichvar
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 patc
ewrite 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?
d be a good
time to reconsider using inline assembly instead of nasm to minimize
the amount of asm code? It would be useful to know how much are the
individual asm routines actually faster, it has been a long time
since I played with it.
--
Miroslav Lichvar
useful: -asm,
-gcc43 and -hidesyms.
I can prepare proper git patches, if interested.
Thanks,
--
Miroslav Lichvar
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 patc
On Fri, Mar 14, 2008 at 07:36:31PM +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
>
than the _ia32_bswap
function. If the code produced by MSVC is faster as well, I'd suggest
to remove the assembly function completely and avoid the problems with
text relocation (sf bug #1793536).
--
Miroslav Lichvar
Index: src/libFLAC/bitrea
sum;
FLAC__ASSERT(order > 0);
--
Miroslav Lichvar
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
ression ratio
90.3% for the grasshopper sample.
--
Miroslav Lichvar
Index: src/libFLAC/stream_encoder.c
===
RCS file: /cvsroot/flac/flac/src/libFLAC/stream_encoder.c,v
retrieving revision 1.136
diff -u -r1.136 stream_encoder.c
--- sr
t;>' operator 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
with all possible values of channels/bps. Even when
channels = bps = 0 as there is always the offset +64. It will just
take more iterations.
> maybe it's best to not try and solve that case though.
Using values from the last decoded frame is probably the best
solution.
--
Miroslav Lichvar
7;t decoded a frame. There should be a fallback
for this case.
--
Miroslav Lichvar
Index: stream_decoder.c
===
RCS file: /cvsroot/flac/flac/src/libFLAC/stream_decoder.c,v
retrieving revision 1.119
diff -u -r1.119 stream_decoder.c
---
et_buffer with an unsigned * so maby this will break elseware now.
>
> 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 ma
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
won't 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
---
iable
10s 53 53 9 9
100s87 9 8 8
- 1 162010 13
Attached is the new patch.
--
Miroslav Lichvar
Index: stream_deco
4-February/001508.html
> see 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
ally useful though
* reasonable partitioning for frames with blocksize != 2^something,
would be good for variable blocksize coding
--
Miroslav Lichvar
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
e little endian, but
shell function test_file() in test_streams.sh uses --endian=big.
--
Miroslav Lichvar
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
for seekable stream decoder, originally posted on 09/07/2003.
--
Miroslav Lichvar
--- seekable_stream_decoder.c.orig 2005-01-25 05:18:31.0 +0100
+++ seekable_stream_decoder.c 2005-01-25 23:39:03.0 +0100
@@ -857,11 +857,11 @@
FLAC__bool seek_to_absolute_sample_(FLAC__SeekableS
:40 +0100, subject "bitbuffer optimizations". I
don't know if it is still possible to apply the patch to the current
code (I have written my own decoder for my limited purposes), but at
least you can give it a try.
--
Miroslav Lichvar
___
Flac
95 matches
Mail list logo
