lvqcl wrote:
lvqcl wrote:
I tried myself to fix this message. How about the attached patch?
The second, shorter version of the patch is attached.
Not sure which is better.
I like this one. Applied.
Thanks,
Erik
--
An update for the patch
http://lists.xiph.org/pipermail/flac-dev/2014-June/004846.html
--endian and --sign aren't just options for raw input, but also
for raw output. So the help text was corrected.
help_raw.patch
Description: Binary data
___
1)
lpc.c, FLAC__lpc_quantize_coefficients():
This function declares const int nshift = -(*shift) variable
when *shift is less than 0. Then nshift is used in the loop:
for(i = 0; i order; i++) {
error += lp_coeff[i] / (1 nshift);
This patch adds const int pshift = *shift variable.
Anybody read it?
Hi!
Can anyone name hardware decoders that can't decode non-subset FLAC stream?
Which hardware device or software fails for mismatch of any conditions
described at http://xiph.org/flac/format.html#subset?
Thanks in advance!
___
op 02-07-14 17:35, Барт Гопник schreef:
Anybody read it?
As far as I know, there is no list that keeps track of devices
that only play subset files. That's because there are quite a
few ways to be non-subset. My portable audio player starts to
stutter mildly when files have LPC blocks with a
lvqcl wrote:
The 1st patch fixes compiling of test_libFLAC with MSVC.
The 2nd patch fixes Makefile.lite build system
(I don't use it, but this patch is really simple...)
Good catch. Applied.
Erik
--
--
Erik de Castro Lopo
lvqcl wrote:
Anybody knows the reason for the following code
(you can see it in flac/decode.c, flac/encode.c, libFLAC/fixed.c and
libFLAC/stream_decoder.c) ?
snip
Is it MSVC6 specific? The following web pages seem to confirm this:
Erik de Castro Lopo wrote:
That's a really good question. Haven't was already dropped support for
MSVC6? If so, we should drop this #ifdef hackery. Can test this without
the hackery for versions of MSVC 6?
I don't have VC 2002/2003, but the oldest Visual Studio that FLAC supports
is MSVS
Hi all,
I thought it was a good idea to get an overview of the
developments since the release of 1.3.0, so here are a few graphs.
The first was compiled with GCC 4.8, the second was compiled
with MSVC 2013. Both were tested on a Kubuntu 14.04 machine,
with an Intel Core 2 Duo T9600 (SSE
Erik de Castro Lopo wrote:
I much prefer the second version because its such a trivial patch.
Actually, no, the second is better because its explicit and has
comments.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
lvqcl wrote:
I don't have VC 2002/2003, but the oldest Visual Studio that FLAC supports
is MSVS 2005 anyway. It can compile FLAC__uint64 - FLAC__double conversion
without intermediate FLAC__int64. So this spoon feed isn't necessary.
(found another place with this double conversion, inside
Erik de Castro Lopo wrote:
...
Howver, exactly because it is such a trivial patch it would be
easy for someone to remove the + 4 again and break it.
Before I commit this, I'd like to have a test that triggers this
problem. Let me work on that.
Would not a /* Do not remove */ comment be
Erik de Castro Lopo wrote:
Hadn't decided yet. Please give me 12 hours. Gotta go to
work now :-)
All right.
BTW, test_libFLAC is still broken for MSVS: CPU_IS_LITTLE_ENDIAN
is undefined. It's possible to add the definition for this
preprocessor macro to test_libFLAC.vcproj, but maybe there
My portable audio player starts to stutter mildly when files have LPC blocks
with a order larger than 12, but I'm not sure it will play files with very
large blocksizes or unusual samplerates at all.
Can you name model of your portable audio player please?
14 matches
Mail list logo
