Re: [flac-dev] How to check/test existing FLAC stream for Subset?
check the resulting file for subset blocksizes, sample rates, bits per sample, LPC filter order and rice partition order. That's all parameters that I need to check? FLAC tools have a lots of warnings about non-subset files during encoding, but unfortunately don't have easy way to check/test existing FLAC stream for subset compliance. flac -a generates the big text file that has data about each frame and subframe. But looks like I need parser and statistics tools to answer on question about subset compliance of stream. Looks like metaflac --show-min-blocksize --show-max-blocksize --show-sample-rate --show-bps is more useful, but look like unfortunately there is no switches to show LPC filter order and Rice partition order in MataFLAC tool. It would be nice if anybody add switches to show more parameters like LPC filter order and Rice partition order and checking for subset compliance of stream to MetaFLAC tool. I understand that FLAC is free open source project and nobody owes nobody nothing and don't know how hard to implement these features, because I'm not a programmer, I'm just powered user only. My task (specific purpose is science research/experiment at the university) is achieve the maximum possible compression ratio using reference FLAC encoder and FFMPEG's FLAC encoder, but stream should be FLAC subset. With reference FLAC encoder all is clear due to excellent exhaustive documentation about each available parameters :), with FFMPEG's FLAC encoder unfortunately is not. :( Does the following FFMPEG's FLAC encoder options affect the subset compliance of stream? -lpc_type intE...A... LPC algorithm (from -1 to 3) (default -1) none E...A... fixedE...A... levinson E...A... cholesky E...A... -lpc_passesintE...A... Number of passes to use for Cholesky factorization during LPC analysis (from 1 to INT_MAX) (default 2) -prediction_order_method intE...A... Search method for selecting prediction order (from -1 to 5) (default -1) estimation E...A... 2level E...A... 4level E...A... 8level E...A... search E...A... log E...A... I can't find anything about e.g. Levinson-Durbin recursion with Welch window and Cholesky factorization (and number of its passes) LPC algorithms and estimation, 2level, 4level, 8level, search and log search methods for selecting prediction order in FLAC documentation, therefore I can't know how these parameters affect to subset compliance of stream. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Conflict in float_t type
Miroslav Lichvar wrote: Hi, I'm trying to build current git on i386, but it fails with the following error: make[3]: Entering directory '/tmp/flac/src/share' CC grabbag/replaygain.lo In file included from grabbag/replaygain.c:38:0: ../../include/share/replaygain_analysis.h:45:15: error: conflicting types for 'float_t' typedef float float_t; /* Type used for filtering */ ^ 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 double float_t; /* `float' expressions are evaluated as What distro? What package and what version of the what package installed that file? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Conflict in float_t type
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 double float_t; /* `float' expressions are evaluated as What distro? What package and what version of the what package installed that file? Fedora rawhide, glibc-headers-2.19.90-21.fc21.1.i686. Looking at the file in an older Fedora, it doesn't seem to be something new. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] [PATCH] stream_encoder : Improve selection of residual accumulator width
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 larger than bps.
It slightly improves the performance with standard encoding levels and
16-bit files as the 17-bit side channel can still be processed with the
32-bit accumulator and correctly selects the 64-bit accumulator with
very large 16-bit partitions.
This is related to commits 6f7ec60c and 187e596e.
---
src/libFLAC/include/private/stream_encoder.h | 6 ++
src/libFLAC/stream_encoder.c | 14 ++
src/libFLAC/stream_encoder_intrin_sse2.c | 3 ++-
src/libFLAC/stream_encoder_intrin_ssse3.c| 3 ++-
4 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/src/libFLAC/include/private/stream_encoder.h
b/src/libFLAC/include/private/stream_encoder.h
index d26039a..8147f9e 100644
--- a/src/libFLAC/include/private/stream_encoder.h
+++ b/src/libFLAC/include/private/stream_encoder.h
@@ -37,6 +37,12 @@
#include config.h
#endif
+/*
+ * 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
+
#if (defined FLAC__CPU_IA32 || defined FLAC__CPU_X86_64) defined
FLAC__HAS_X86INTRIN
#include private/cpu.h
#include FLAC/format.h
diff --git a/src/libFLAC/stream_encoder.c b/src/libFLAC/stream_encoder.c
index e64ece2..8928a39 100644
--- a/src/libFLAC/stream_encoder.c
+++ b/src/libFLAC/stream_encoder.c
@@ -3872,10 +3872,9 @@ void precompute_partition_info_sums_(
FLAC__ASSERT(default_partition_samples predictor_order);
#if defined(FLAC__CPU_IA32) !defined FLAC__NO_ASM defined FLAC__HAS_NASM
0
- /* WATCHOUT: + bps is an assumption that the average residual
magnitude will not be more than bps bits */
- /* previously the condition was:
if(FLAC__bitmath_ilog2(default_partition_samples) + bps 32) */
- /* see
http://git.xiph.org/?p=flac.git;a=commit;h=6f7ec60c7e7f05f5ab0b1cf6b7b0945e44afcd4b
*/
- if(bps = 16) {
+ /* WATCHOUT: + bps + FLAC__MAX_EXTRA_RESIDUAL_BPS is the maximum
+* assumed size of the average residual magnitude */
+ if(FLAC__bitmath_ilog2(default_partition_samples) + bps +
FLAC__MAX_EXTRA_RESIDUAL_BPS 32) {
FLAC__precompute_partition_info_sums_32bit_asm_ia32_(residual,
abs_residual_partition_sums, residual_samples + predictor_order,
predictor_order, min_partition_order, max_partition_order);
return;
}
@@ -3884,10 +3883,9 @@ void precompute_partition_info_sums_(
/* first do max_partition_order */
{
unsigned partition, residual_sample, end =
(unsigned)(-(int)predictor_order);
- /* WATCHOUT: + bps is an assumption that the average residual
magnitude will not be more than bps bits */
- /* previously the condition was:
if(FLAC__bitmath_ilog2(default_partition_samples) + bps 32) */
- /* see
http://git.xiph.org/?p=flac.git;a=commit;h=6f7ec60c7e7f05f5ab0b1cf6b7b0945e44afcd4b
*/
- if(bps = 16) {
+ /* WATCHOUT: + bps + FLAC__MAX_EXTRA_RESIDUAL_BPS is the
maximum
+* assumed size of the average residual magnitude */
+ if(FLAC__bitmath_ilog2(default_partition_samples) + bps +
FLAC__MAX_EXTRA_RESIDUAL_BPS 32) {
FLAC__uint32 abs_residual_partition_sum;
for(partition = residual_sample = 0; partition
partitions; partition++) {
diff --git a/src/libFLAC/stream_encoder_intrin_sse2.c
b/src/libFLAC/stream_encoder_intrin_sse2.c
index bef5545..4e9d5db 100644
--- a/src/libFLAC/stream_encoder_intrin_sse2.c
+++ b/src/libFLAC/stream_encoder_intrin_sse2.c
@@ -37,6 +37,7 @@
#ifndef FLAC__NO_ASM
#if (defined FLAC__CPU_IA32 || defined FLAC__CPU_X86_64) defined
FLAC__HAS_X86INTRIN
#include private/stream_encoder.h
+#include private/bitmath.h
#ifdef FLAC__SSE2_SUPPORTED
#include stdlib.h/* for abs() */
@@ -58,7 +59,7 @@ void FLAC__precompute_partition_info_sums_intrin_sse2(const
FLAC__int32 residual
unsigned e1, e3;
__m128i mm_res, mm_sum, mm_mask;
- if(bps = 16) {
+ if(FLAC__bitmath_ilog2(default_partition_samples) + bps +
FLAC__MAX_EXTRA_RESIDUAL_BPS 32) {
for(partition = residual_sample = 0; partition
partitions; partition++) {
end += default_partition_samples;
mm_sum = _mm_setzero_si128();
diff --git a/src/libFLAC/stream_encoder_intrin_ssse3.c
b/src/libFLAC/stream_encoder_intrin_ssse3.c
index 95b5f62..669536a 100644
--- a/src/libFLAC/stream_encoder_intrin_ssse3.c
+++ b/src/libFLAC/stream_encoder_intrin_ssse3.c
@@
Re: [flac-dev] Lets work towards a new version
Erik de Castro Lopo wrote: VS 2005/2008 use .vcproj files, and VS 2010/2012/2013 use .vcxproj and .vcxproj.filters files, so it's possible to have two sets of MSVS solution files: one for 2005/2008 and another for 2010/2012/2013. But there will be two .sln files: current FLAC.sln and new FLAC-vs2013.sln (or FLAC-vs201x.sln? or is it better to rename FLAC.sln to FLAC-vs2005.sln?) What do you think? I think having 64 bit builds on Windows would be a good thing. Unfortunately since I don't have *any* Windows machines to even test on, zero recent experience on Windows and little desire to reaquaint myself with Windows this is not a job for me. However, I am more than happy to have someone else undertake this task, and will help where I can. As for what versions of MSVC we should support, I am not really qualified to say. What do other similar projects do? Eg Audacity? Audacity still uses VS2008 and slowly tries to migrate to VS2012. But as stated at http://wiki.audacityteam.org/wiki/Developing_On_Windows, Audacity is currently a 32-bit only application. So it doesn't need 64-bit builds. Currently its trunk contains 'audacity.sln' made with Visual C++ Express 2008 and 'audacity-vs2012_EXPERIMENTAL.sln' made with Visual Studio Express 2012 for Windows Desktop. My main concern about having multiple build systems is the maintenance burden. As long as that burden is minor I'm happy to accept what people are willing to contribute. I personally will support the autotools based build system and can also support the Makefile.lite build system. That's why I asked about unused .nasm files: it's better to do all the changes to .vcproj files first, and only then convert them to .vcxproj. VC projects contain relative paths such as ..\..\include. Is it better to leave them as is or to change to something like $(SolutionDir)include? That sounds like a good idea. I opened libFLAC_static.vcproj in a text editor and it turns out that it contains relative paths anyway: File RelativePath=..\..\include\FLAC\stream_encoder.h/File So replacing relative paths in AdditionalIncludeDirectories entries seems rather pointless, sorry. Is it better to remove these files from Makefile and .vcproj files, or to leave them? I don't think that they will become useful again, but who knows... I think they should be deleted in a commit that says something like Removing old nasm versions of some functions. That will clearly mark that commit so that if needed the files can be easily retrieved from the Git history. Should these patches also remove those .nasm files from the source tree or not? (currently src/libFLAC/ia32 folder contains unused lpc_asm-unrolled.nasm file, so why remove unused bitreader_asm.nasm and stream_encoder_asm.nasm files?) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] stream_encoder : Improve selection of residual accumulator width
Miroslav Lichvar wrote: 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 larger than bps. It slightly improves the performance with standard encoding levels and 16-bit files as the 17-bit side channel can still be processed with the 32-bit accumulator and correctly selects the 64-bit accumulator with very large 16-bit partitions. BTW, what can you say about the following place in stream_decoder.c in read_subframe_lpc_() function: /*@@ technically not pessimistic enough, should be more like if( (FLAC__uint64)order * FLAC__uint64)1)bps)-1) * ((1subframe-qlp_coeff_precision)-1) (((FLAC__uint64)-1) 32) ) */ if(bps + subframe-qlp_coeff_precision + FLAC__bitmath_ilog2(order) = 32) Is it really not pessimistic enough? Can it be changed similarly to your patch for stream_encoder.c? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Lets work towards a new version
lvqcl wrote: Audacity still uses VS2008 and slowly tries to migrate to VS2012. But as stated at http://wiki.audacityteam.org/wiki/Developing_On_Windows, Audacity is currently a 32-bit only application. So it doesn't need 64-bit builds. Currently its trunk contains 'audacity.sln' made with Visual C++ Express 2008 and 'audacity-vs2012_EXPERIMENTAL.sln' made with Visual Studio Express 2012 for Windows Desktop. Ok, Audacity is not a good example to follow. We need to find out what some other common used cross platform project is doing. Preferably more than one project. My main concern about having multiple build systems is the maintenance burden. As long as that burden is minor I'm happy to accept what people are willing to contribute. I personally will support the autotools based build system and can also support the Makefile.lite build system. That's why I asked about unused .nasm files: it's better to do all the changes to .vcproj files first, and only then convert them to .vcxproj. +1 VC projects contain relative paths such as ..\..\include. Is it better to leave them as is or to change to something like $(SolutionDir)include? That sounds like a good idea. I opened libFLAC_static.vcproj in a text editor and it turns out that it contains relative paths anyway: File RelativePath=..\..\include\FLAC\stream_encoder.h/File So replacing relative paths in AdditionalIncludeDirectories entries seems rather pointless, sorry. Ok, you know more about this than me. Is it better to remove these files from Makefile and .vcproj files, or to leave them? I don't think that they will become useful again, but who knows... I think they should be deleted in a commit that says something like Removing old nasm versions of some functions. That will clearly mark that commit so that if needed the files can be easily retrieved from the Git history. Should these patches also remove those .nasm files from the source tree or not? Yes. (currently src/libFLAC/ia32 folder contains unused lpc_asm-unrolled.nasm file, so why remove unused bitreader_asm.nasm and stream_encoder_asm.nasm files?) I don't see any point in keeping files in release tarballs or in Git that provide no value. Documentation provides value, but unused source code does not. All the various build system files should be cleansed of references to these files and then we need a single commit that removes them. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Lets work towards a new version
On 2014-06-19 6:01 AM, Erik de Castro Lopo wrote: Ok, Audacity is not a good example to follow. We need to find out what some other common used cross platform project is doing. Preferably more than one project. FWIW, the other xiph codecs have parallel sets of MSVC project files under the win32 directory. We did this because while newer versions can generally open/update older project files, the reverse is true and many developers said they weren't upgrading. libogg has separate project files for VS2003, VS2005, VS2008, VS2010, and VS6. That said, for Opus we've only been maintaining VS2010 project files (tested with both VS2010 and VS2013 Express) and haven't had any complaints. I'd suggest a single set of project files which work with a previous but recent release of the free Visual Studio Express, and see if that works for people. -r ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] stream_encoder : Improve selection of residual accumulator width
On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: BTW, what can you say about the following place in stream_decoder.c in read_subframe_lpc_() function: /*@@ technically not pessimistic enough, should be more like if( (FLAC__uint64)order * FLAC__uint64)1)bps)-1) * ((1subframe-qlp_coeff_precision)-1) (((FLAC__uint64)-1) 32) ) */ if(bps + subframe-qlp_coeff_precision + FLAC__bitmath_ilog2(order) = 32) Is it really not pessimistic enough? Can it be changed similarly to your patch for stream_encoder.c? Good question. I'm not sure what exactly Josh meant by that comment. The git message says just minor comments. I think the right size of the expression was meant to be (FLAC__uint64)132, otherwise it doesn't make much sense to me. With that it can rewritten in log2 as bps + subframe-qlp_coeff_precision + FLAC__bitmath_ilog2(order - 1) 32 This is indeed more pessimistic that the currently used check ( 32 vs = 32), but I think both make a mistake that the qlp coefficients and residuals are unsigned integers and are actually more pessimistic than they would need to be if residuals were at most bps wide. With signed multiplication I think the correct check would actually be bps + subframe-qlp_coeff_precision + FLAC__bitmath_ilog2(order) - 1 = 32 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? 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 mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Lets work towards a new version
Ralph Giles gi...@thaumas.net писал(а) в своём письме Thu, 19 Jun 2014 17:15:27 +0400: FWIW, the other xiph codecs have parallel sets of MSVC project files under the win32 directory. We did this because while newer versions can generally open/update older project files, the reverse is true and many developers said they weren't upgrading. libogg has separate project files for VS2003, VS2005, VS2008, VS2010, and VS6. MSVS 2005 project for libogg contains 2 *.vcproj files in a win32/VS2005 folder. In FLAC, there are 27 *.vcproj files scattered all over its source tree. It's a complicated task to move them into one separate folder. That said, for Opus we've only been maintaining VS2010 project files (tested with both VS2010 and VS2013 Express) and haven't had any complaints. I'd suggest a single set of project files which work with a previous but recent release of the free Visual Studio Express, and see if that works for people. VS 2010/2102/2013 project files are forward and backward compatible. But it's not possible to open them with older versions such as VS2005 and VS2008, and unfortunately there are developers that still use these versions. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Lets work towards a new version
Erik de Castro Lopo mle...@mega-nerd.com писал(а) в своём письме Thu, 19 Jun 2014 17:01:26 +0400: (currently src/libFLAC/ia32 folder contains unused lpc_asm-unrolled.nasm file, so why remove unused bitreader_asm.nasm and stream_encoder_asm.nasm files?) I don't see any point in keeping files in release tarballs or in Git that provide no value. Documentation provides value, but unused source code does not. Well, lpc_asm-unrolled.nasm exists only in Git but not in any of release tarballs. And there are no significant changes for it since Jun'2001. Anybody knows its purpose? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] stream_encoder : Improve selection of residual accumulator width
Miroslav Lichvar wrote: if(bps + subframe-qlp_coeff_precision + FLAC__bitmath_ilog2(order) = 32) Is it really not pessimistic enough? Can it be changed similarly to your patch for stream_encoder.c? Good question. I'm not sure what exactly Josh meant by that comment. The git message says just minor comments. Now I wonder why evaluate_lpc_subframe_() function in stream_encoder.c contains almost the same code, but without any comments that it's not enough pessimistic: evaluate_lpc_subframe_(): if(subframe_bps + qlp_coeff_precision + FLAC__bitmath_ilog2(order) = 32) if(subframe_bps = 16 qlp_coeff_precision = 16) encoder-private_-local_lpc_compute_residual_from_qlp_coefficients_16bit(...); else encoder-private_-local_lpc_compute_residual_from_qlp_coefficients(...); else encoder-private_-local_lpc_compute_residual_from_qlp_coefficients_64bit(...); vs. read_subframe_lpc_(): 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 decoder-private_-local_lpc_restore_signal(...); else decoder-private_-local_lpc_restore_signal_64bit(...); ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] stream_encoder : Improve selection of residual accumulator width
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 how common are such streams. I
patched flac to print a warning on decoding or testing when this is
detected, but didn't find any files with this problem in my (small)
music collection.
If someone has a large collection and some cycles to spare, can you please
consider compiling flac from git with the attached patch and see if
you have any files that fail with flac -t ?
With the known problem file (snippet6.wav) encoded by 1.3.0 it prints
this:
WARNING: residual -11025151 wider than bps 24
WARNING: residual 41873263 wider than bps 24
WARNING: residual -67175215 wider than bps 24
WARNING: residual 69950995 wider than bps 24
WARNING: residual -67108864 wider than bps 24
...
WARNING: residual 11227392 wider than bps 24
WARNING: residual -8754288 wider than bps 24
snippet6.flac: ERROR, MD5 signature mismatch
Thanks,
--
Miroslav Lichvar
diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c
index ddd8979..82318ae 100644
--- a/src/libFLAC/stream_decoder.c
+++ b/src/libFLAC/stream_decoder.c
@@ -99,7 +99,7 @@ static FLAC__bool read_subframe_constant_(FLAC__StreamDecoder
*decoder, unsigned
static FLAC__bool read_subframe_fixed_(FLAC__StreamDecoder *decoder, unsigned
channel, unsigned bps, const unsigned order, FLAC__bool do_full_decode);
static FLAC__bool read_subframe_lpc_(FLAC__StreamDecoder *decoder, unsigned
channel, unsigned bps, const unsigned order, FLAC__bool do_full_decode);
static FLAC__bool read_subframe_verbatim_(FLAC__StreamDecoder *decoder,
unsigned channel, unsigned bps, FLAC__bool do_full_decode);
-static FLAC__bool read_residual_partitioned_rice_(FLAC__StreamDecoder
*decoder, unsigned predictor_order, unsigned partition_order,
FLAC__EntropyCodingMethod_PartitionedRiceContents *partitioned_rice_contents,
FLAC__int32 *residual, FLAC__bool is_extended);
+static FLAC__bool read_residual_partitioned_rice_(FLAC__StreamDecoder
*decoder, unsigned predictor_order, unsigned partition_order,
FLAC__EntropyCodingMethod_PartitionedRiceContents *partitioned_rice_contents,
FLAC__int32 *residual, FLAC__bool is_extended, int bps);
static FLAC__bool read_zero_padding_(FLAC__StreamDecoder *decoder);
static FLAC__bool read_callback_(FLAC__byte buffer[], size_t *bytes, void
*client_data);
#if FLAC__HAS_OGG
@@ -2572,7 +2572,7 @@ FLAC__bool read_subframe_fixed_(FLAC__StreamDecoder
*decoder, unsigned channel,
switch(subframe-entropy_coding_method.type) {
case FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE:
case FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2:
- if(!read_residual_partitioned_rice_(decoder, order,
subframe-entropy_coding_method.data.partitioned_rice.order,
decoder-private_-partitioned_rice_contents[channel],
decoder-private_-residual[channel],
/*is_extended=*/subframe-entropy_coding_method.type ==
FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2))
+ if(!read_residual_partitioned_rice_(decoder, order,
subframe-entropy_coding_method.data.partitioned_rice.order,
decoder-private_-partitioned_rice_contents[channel],
decoder-private_-residual[channel],
/*is_extended=*/subframe-entropy_coding_method.type ==
FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2, bps))
return false;
break;
default:
@@ -2651,7 +2651,7 @@ FLAC__bool read_subframe_lpc_(FLAC__StreamDecoder
*decoder, unsigned channel, un
switch(subframe-entropy_coding_method.type) {
case FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE:
case FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2:
- if(!read_residual_partitioned_rice_(decoder, order,
subframe-entropy_coding_method.data.partitioned_rice.order,
decoder-private_-partitioned_rice_contents[channel],
decoder-private_-residual[channel],
/*is_extended=*/subframe-entropy_coding_method.type ==
FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2))
+ if(!read_residual_partitioned_rice_(decoder, order,
subframe-entropy_coding_method.data.partitioned_rice.order,
decoder-private_-partitioned_rice_contents[channel],
decoder-private_-residual[channel],
/*is_extended=*/subframe-entropy_coding_method.type ==
FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2, bps))
return false;
break;
default:
@@ -2703,7 +2703,7 @@ FLAC__bool read_subframe_verbatim_(FLAC__StreamDecoder
*decoder, unsigned channe
return true;
}
-FLAC__bool read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder,
Re: [flac-dev] [PATCH] stream_encoder : Improve selection of residual accumulator width
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) + FLAC__MAX_EXTRA_RESIDUAL_BPS - 1 = 32) if(subframe_bps + FLAC__MAX_EXTRA_RESIDUAL_BPS = 16 qlp_coeff_precision = 16) On second thought, this is probably not necessary. The residual seems to be always treated as 32-bit in the LPC encoding and decoding functions, even in the MMX assembly if I'm reading it correctly. It doesn't matter if it's wider than the original signal. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] How to check/test existing FLAC stream for Subset?
op 19-06-14 11:20, Барт Гопник schreef: That's all parameters that I need to check? That is correct. See http://xiph.org/flac/format.html, it says The Subset makes the following limitations on what may be used in the stream: - The blocksize bits in the frame header must be 0001-1110. The blocksize must be =16384; if the sample rate is = 48000Hz, the blocksize must be =4608. - The sample rate bits in the frame header must be 0001-1110. - The bits-per-sample bits in the frame header must be 001-111. - If the sample rate is = 48000Hz, the filter order in LPC subframes must be less than or equal to 12, i.e. the subframe type bits in the subframe header may not be 101100-11. - The Rice partition order in a Rice-coded residual section must be less than or equal to 8. So those are all restrictions you have to check for. but stream should be FLAC subset. What is the reason you're restricting yourself to subset? Does it have to be decodeable on certain hardware? Does the following FFMPEG's FLAC encoder options affect the subset compliance of stream? [...] I can't find anything about e.g. Levinson-Durbin recursion with Welch window and Cholesky factorization (and number of its passes) LPC algorithms and estimation, 2level, 4level, 8level, search and log search methods for selecting prediction order in FLAC documentation, therefore I can't know how these parameters affect to subset compliance of stream. Those are parameters that affect the way the encoder searches for ways to compress, but it doesn't change the time or amount of memory the decoder needs to decode the file. They are not detailed in the documentation because those options do not show up in the resulting file, it is an encoder internal. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Lets work towards a new version
op 19-06-14 02:00, Erik de Castro Lopo schreef: Hi all, [...] Anything else I've forgotten or people would like to see? Like I reported just before the release of 1.3.0 (mail of Fri, 05 Apr 2013 08:25:10 +0200, to be specific), compiling on Raspbian (Debian Wheezy, GCC 4.6) returns quite some warnings of the type -Wcast-align. CC lpc_intrin_sse2.lo CC lpc_intrin_sse41.lo CC md5.lo md5.c: In function 'format_input_': md5.c:282:25: warning: cast increases required alignment of target type [-Wcast-align] md5.c:288:24: warning: cast increases required alignment of target type [-Wcast-align] CC memory.lo CC metadata_iterators.lo [...] CCLD libFLAC-static.la make[4]: Leaving directory `/home/pi/bin/flac/src/libFLAC' make[3]: Leaving directory `/home/pi/bin/flac/src/libFLAC' Making all in flac make[3]: Entering directory `/home/pi/bin/flac/src/flac' CC analyze.o CC decode.o decode.c: In function ‘write_callback’: decode.c:971:28: warning: cast increases required alignment of target type [-Wcast-align] decode.c:972:28: warning: cast increases required alignment of target type [-Wcast-align] decode.c:973:28: warning: cast increases required alignment of target type [-Wcast-align] decode.c:974:28: warning: cast increases required alignment of target type [-Wcast-align] CC encode.o encode.c:120:34: warning: cast increases required alignment of target type [-Wcast-align] encode.c:121:33: warning: cast increases required alignment of target type [-Wcast-align] CC foreign_metadata.o CC main.o CC local_string_utils.o One other issue that I've brought up before but hasn't been fixed yet: none of the people that have contributed to FLAC in the last few years (save Miroslav) are in the AUTHORS file :) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Lets work towards a new version
Martijn van Beurden wrote: One other issue that I've brought up before but hasn't been fixed yet: none of the people that have contributed to FLAC in the last few years (save Miroslav) are in the AUTHORS file :) flac-website Git is also slightly outdated (dead links, some text is obsolete, etc). Maybe it's time to update it too? And, doc/html/* in flac Git is even older. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] stream_encoder : Improve selection of residual accumulator width
Miroslav Lichvar wrote: I think it would be interesting to know how common are such streams. I patched flac to print a warning on decoding or testing when this is detected, but didn't find any files with this problem in my (small) music collection. If someone has a large collection and some cycles to spare, can you please consider compiling flac from git with the attached patch and see if you have any files that fail with flac -t ? With the known problem file (snippet6.wav) encoded by 1.3.0 it prints this: WARNING: residual -11025151 wider than bps 24 WARNING: residual 41873263 wider than bps 24 WARNING: residual -67175215 wider than bps 24 WARNING: residual 69950995 wider than bps 24 WARNING: residual -67108864 wider than bps 24 ... WARNING: residual 11227392 wider than bps 24 WARNING: residual -8754288 wider than bps 24 snippet6.flac: ERROR, MD5 signature mismatch It seems quite common for 16-bit files: WARNING: residual 43536 wider than bps 16 WARNING: residual 38012 wider than bps 16 WARNING: residual 35263 wider than bps 16 WARNING: residual 40668 wider than bps 16 WARNING: residual -34199 wider than bps 16 WARNING: residual -33828 wider than bps 16 WARNING: residual -33891 wider than bps 16 WARNING: residual -33540 wider than bps 16 WARNING: residual -36793 wider than bps 16 WARNING: residual -38870 wider than bps 16 WARNING: residual -35610 wider than bps 16 WARNING: residual -39849 wider than bps 16 WARNING: residual -38411 wider than bps 16 WARNING: residual -33430 wider than bps 16 WARNING: residual -34989 wider than bps 16 I don't have 24-bit FLAC files in my music library. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Lets work towards a new version
op 19-06-14 19:31, lvqcl schreef: flac-website Git is also slightly outdated (dead links, some text is obsolete, etc). Maybe it's time to update it too? Yeah, I might do that sometime soon. And, doc/html/* in flac Git is even older. I've cleaned that up quite recently: http://git.xiph.org/?p=flac.git;a=commit;h=943384d7c3301c1fb54096e2250db36435d3943c Is there anything specific you're referring too? Aside from quite a lot of links to the sourceforge bugtracker that are now 301-forwarded, there aren't much 404's to fix there, right? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] stream_encoder : Improve selection of residual accumulator width
op 19-06-14 20:17, lvqcl schreef: It seems quite common for 16-bit files: I second that. Apparently it depends on the kind of music, some albums have no warnings (mostly classical music it seems), some have over 20 per file. I've seen a few with 100 per file (things like rock and heavy metal). Most of the FLAC files were encoded with FLAC 1.2.1. The same is true for 24-bit files. I checked some orchestral music with no warnings, while NIN's The Slip (downloadable free of charge in 96/24) does, track 2 gives ~ 1900 warnings. These files too, were encoded with FLAC 1.2.1 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] R128gain metaflac
On Wed, 18 Jun 2014 17:56:01 -0700 Timothy B. Terriberry tterr...@xiph.org wrote: Ian Nartowicz wrote: It is certainly the biggest issue. Sure it should be simple to address, but nobody seems willing to do so. The only response I've had so far is that the output gain should *always* be applied, yet it *might* be an album gain. It can't be both and there is no way to tell which. Sorry, but that makes it Well, make a proposal on the IETF list that addresses this (the FLAC list probably isn't the right place for this discussion). So far the only discussion there has been I think this is broken but I don't know what to do, and, I don't think the IETF should be allowed to say what goes in the tags of an Ogg Opus file. This could be as simple as just adding another tag which says whether or not the header gain is an album gain. I'd be entirely comfortable with an additional defined tag for an R128 album gain, but doesn't it mostly defeat the point of the output gain field in the first place? Output gain would now, in most cases, be zero, and replaygain would no longer be applied by default by all decoders. The issue the header gain was trying to solve is that something close to half of all software that plays Vorbis completely ignores replaygain tags. So if you tag a file you have literally no idea what volume a player will play it back at compared to an untagged file. The second issue is the lack of defined peak tags. I could care less, but some people care deeply and it is a relatively standard feature of music players. The Opus spec doesn't define such tags, but it does explicitly say not to use the REPLAYGAIN* tags. Again that's just not viable. The only usage we could find of the peak tags in the wild was people doing crazy things, like limiting the gain they applied so the peak could not go above 1.0 (which makes the actual gain stored in the file useless, and, like above, destroys the predictability about what volume a file will be played back at, since very little software looks at these tags at all). If you do any kind of resampling they're not reliable anyway, so there did not seem to be any point to add them (and adding them seemed actively harmful). I'm certainly no huge fan of the peak scaling approach, not least for the reason you describe of destroying the normalisation, but it is widely used, widely supported, and a requested feature. That is really the only end use for peak tags, but it is quite common. I think you are too harsh in describing the playback volume as unpredictable. I'm not aware of any tool that plays back with gain scaled down to avoid peak clipping without the user having control over that, and virtually always it is off by default. A common alternative in many gain calculation tools is to reduce the gain tag if clipping is detected, but that seems to me an even worse solution in destroying the normalisation while giving the end user no choice. Possibly the biggest problem occurs when a music player attempts to scale to avoid clipping without there being peak tags, that is just nasty. Again, if Opus doesn't offer support then people who want it will just keep using the evil REPLAYGAIN* tags, and probably their associated gain tags, and probably keep asking me to turn off the Opus gain. --ian ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Lets work towards a new version
On Fri, Jun 20, 2014 at 1:05 AM, lvqcl lvqcl.m...@gmail.com wrote: I cannot find anything about the size of METADATA_BLOCK_PICTURE block in http://xiph.org/flac/format.html. Where did you read this? METADATA_BLOCK_HEADER has a 24-bit field to encode the length of METADATA_BLOCK_DATA ; hence the limitation (which not only applies to METADATA_BLOCK_PICTURE but all metadata blocks. Pyt. -- Pierre-Yves Thoulon +33 (0)6 33 39 75 76 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
