Re: [flac-dev] FLAC specification clarification

[Thomas Zander]

On Fri, 26 Jun 2020 at 05:15, Brian Willoughby  wrote:

> That said, there's nothing wrong with adding a note to the specification 
> about the common implementations, particularly the reference library. Then, 
> future developers will know both the precise specification and still have the 
> warning that they risk incompatibility by deviating from the reference 
> implementation.

This sounds reasonable to me. The wording of this note should be very
clear, though.

Thomas
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC specification clarification

[Brian Willoughby]

I am also philosophically opposed to changing the specification.

That said, there's nothing wrong with adding a note to the specification about 
the common implementations, particularly the reference library. Then, future 
developers will know both the precise specification and still have the warning 
that they risk incompatibility by deviating from the reference implementation.

I own devices with FLAC implemented in firmware that is quite different from 
the reference implementation. I wouldn't want to edit the specification to 
narrow it to fit those devices, either.

Brian Willoughby

p.s. I seem to recall using a variable to shift in C, rather than a constant, 
and negative values were accepted. Then again, C started out a little weak with 
regard to certain operations, such as whether shift was signed or unsigned, 
etcetera, and thus my memory might be of a really old, esoteric implementation 
of C.


On Jun 25, 2020, at 5:09 AM, Stephen F. Booth  wrote:
> To me the real question is not whether that portion of the spec has been 
> implemented by any existing encoders/decoders but whether the spec is broken 
> (i.e. cannot be implemented as written). I don't know the rationale for 
> making the LPC shift explicitly signed. In C a negative shift is undefined 
> and it does seem in FLAC__lpc_restore_signal() for example that the LPC shift 
> is used as the argument to a right shift operation. It's possible 
> (generally/conceptually, not necessarily here) a negative shift value could 
> be used to represent a left shift. However, I know very little about linear 
> prediction and how coefficients are chosen and whether that makes sense. If 
> it really is a design flaw in the spec then it makes sense to change it or 
> document that negative shifts are not supported by any known implementation 
> as you suggest.
> 
> Philosophically my objection to changing the spec based on lack of known 
> implementations is that it could be artificially limiting, for example the 
> same argument about breaking existing decoders could be made for 32-bit 
> samples sizes.
> 
> 
> On Mon, Jun 22, 2020 at 1:33 AM Martijn van Beurden  wrote:
>> Yes, this is such a case. However, implementing this in a future 
>> encoder/decoder would break compatibility with most (likely all) existing 
>> decoders, and only in some very, very rare cases where the material is such 
>> that the encoder chooses to use negative shifts, which makes it even harder 
>> to troubleshoot. Furthermore, as this can only be used in very rare cases, 
>> there is no benefit from allowing this.
>> 
>> Op vr 19 jun. 2020 om 18:03 schreef Stephen F. Booth :
>>> Is this a case where something allowed by the specification isn't 
>>> implemented by the reference encoder/decoder (such as 25-32 bits per 
>>> sample) but could be in a different implementation? If so, I am not sure 
>>> whether it makes sense to change the specification based on the reference 
>>> implementation.
>>> 
>>> Stephen
>>> 
>>> On Wed, Jun 17, 2020 at 3:22 PM Martijn van Beurden  
>>> wrote:
 Hi all,
 
 When trying to better understand the way LPC exactly works, I stumbled 
 upon something which, after some digging, was already reported and 
 (partly) fixed: https://sourceforge.net/p/flac/bugs/424/
 
 Apparently, the FLAC specification has a LPC shift that can be both 
 positive and negative, but the encoder specifically makes sure that only 
 positive shifts are encoded and the decoder only accepts positive shifts. 
 The ffmpeg FLAC encoder and decoder show the same behaviour.
 
 Now, the documentation in the source code is fixed, the documentation on 
 the website (which I was looking at) isn't yet. The website format.html 
 states: "Quantized linear predictor coefficient shift needed in bits 
 (NOTE: this number is signed two's-complement)." The source code 
 format.html says "Quantized linear predictor coefficient shift needed in 
 bits (NOTE: this number is signed two's-complement; but, due to 
 implementation details, must be non-negative)."
 
 I was thinking of submitting a patch to the FLAC website git to get the 
 website format.html up-to-date (there have been more changes than just 
 this one), but I feel the line above isn't clear enough. Maybe change it 
 to something like this, to make the wording more similar to the rest of 
 the specification
 
 Quantized linear predictor coefficient shift needed in bits (NOTE: these 
 bits must be 0-0. Originally this was a signed integer, but 
 negative shifts were never implemented). 
 
 Or perhaps:
 
 Quantized linear predictor coefficient shift needed in bits (NOTE: First 
 bit must be zero. Originally this was a signed integer, but negative 
 shifts were never implemented). 
 
 Any thoughts?
 
 Kind regards, Martijn van Beurden
__

Re: [flac-dev] Support for ultra-high sample rates?

[Con Kolivas]

Progress. A simple hack to allow bitrates above 655350 seemed to work
fine for encoding, and the standard reference decoder library decoded
it fine. I'm not sure then in the documentation why it says "the
maximum sample rate is limited by the structure of frame headers to
655350Hz". Perhaps this breaks something elsewhere but the attached
simple patch is working perfectly fine for my use case here! Can
anyone see a reason this might break something elsewhere and couldn't
be incorporated?

Thanks,
Con


On Fri, 26 Jun 2020 at 08:33, Con Kolivas  wrote:
>
> On Fri, 26 Jun 2020 at 00:37, Martijn van Beurden  wrote:
> >
> > Op do 25 jun. 2020 om 16:02 schreef Con Kolivas :
> >>
> >> The idea is to actually use it for playback, not just storage, and
> >> nothing else has the nice asymmetrical fast decompression with such
> >> effective compression (wavpack supports 705/768 but is woefully slow
> >> on decompression and poorly supported). Mostly the sample rates would
> >> be multiples of the common 44.1/48 sample rates so I expect
> >> compression to be equally good with simple extrapolation to bigger
> >> equivalent sized windows.
> >
> >
> > In what setting are you thinking about playback? If this is a lab setting, 
> > creating a small batch script to fetch the samplerate tag and passing it to 
> > a playback program like ffplay doesn't seem a very big deal? If you want 
> > playback on current existing, available hardware, augmenting the spec is 
> > not going to work.
>
> Definitely not a lab setting I'm afraid, I'm just experimenting at
> home with my regular hi-fi gear. I'm just using clementine and roon
> for playback and both load libFLAC so I guess I could create a custom
> flac library to support a bastardised flac container.
>
> Thanks,
> Con
diff --git a/include/FLAC/format.h b/include/FLAC/format.h
index 769ab8af..cf5c25aa 100644
--- a/include/FLAC/format.h
+++ b/include/FLAC/format.h
@@ -125,7 +125,7 @@ extern "C" {
  *  ((2 ^ 16) - 1) * 10; see FLAC format
  *  as to why.
  */
-#define FLAC__MAX_SAMPLE_RATE (655350u)
+#define FLAC__MAX_SAMPLE_RATE (1048575u)
 
 /** The maximum LPC order permitted by the format. */
 #define FLAC__MAX_LPC_ORDER (32u)
diff --git a/src/libFLAC/stream_encoder.c b/src/libFLAC/stream_encoder.c
index 74387ec3..fb9c78ba 100644
--- a/src/libFLAC/stream_encoder.c
+++ b/src/libFLAC/stream_encoder.c
@@ -853,10 +853,10 @@ static FLAC__StreamEncoderInitStatus init_stream_internal_(
 	encoder->private_->loose_mid_side_stereo_frames = (uint32_t)((double)encoder->protected_->sample_rate * 0.4 / (double)encoder->protected_->blocksize + 0.5);
 #else
 	/* 26214 is the approximate fixed-point equivalent to 0.4 (0.4 * 2^16) */
-	/* sample rate can be up to 655350 Hz, and thus use 20 bits, so we do the multiply÷ by hand */
-	FLAC__ASSERT(FLAC__MAX_SAMPLE_RATE <= 655350);
+	/* sample rate can be up to 1048575 Hz, and thus use 20 bits, so we do the multiply÷ by hand */
+	FLAC__ASSERT(FLAC__MAX_SAMPLE_RATE <= 1048575);
 	FLAC__ASSERT(FLAC__MAX_BLOCK_SIZE <= 65535);
-	FLAC__ASSERT(encoder->protected_->sample_rate <= 655350);
+	FLAC__ASSERT(encoder->protected_->sample_rate <= 1048575);
 	FLAC__ASSERT(encoder->protected_->blocksize <= 65535);
 	encoder->private_->loose_mid_side_stereo_frames = (uint32_t)FLAC__fixedpoint_truncFLAC__uint64)(encoder->protected_->sample_rate) * (FLAC__uint64)(26214)) << 16) / (encoder->protected_->blocksize<<16) + FLAC__FP_ONE_HALF);
 #endif
diff --git a/src/libFLAC/stream_encoder_framing.c b/src/libFLAC/stream_encoder_framing.c
index 2c78916d..11ab72ed 100644
--- a/src/libFLAC/stream_encoder_framing.c
+++ b/src/libFLAC/stream_encoder_framing.c
@@ -276,7 +276,9 @@ FLAC__bool FLAC__frame_add_header(const FLAC__FrameHeader *header, FLAC__BitWrit
 		case  48000: u = 10; break;
 		case  96000: u = 11; break;
 		default:
-			if(header->sample_rate <= 255000 && header->sample_rate % 1000 == 0)
+			if(header->sample_rate > 655350)
+u = 0;
+			else if(header->sample_rate <= 255000 && header->sample_rate % 1000 == 0)
 sample_rate_hint = u = 12;
 			else if(header->sample_rate % 10 == 0)
 sample_rate_hint = u = 14;
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Support for ultra-high sample rates?

[Con Kolivas]

On Fri, 26 Jun 2020 at 00:37, Martijn van Beurden  wrote:
>
> Op do 25 jun. 2020 om 16:02 schreef Con Kolivas :
>>
>> The idea is to actually use it for playback, not just storage, and
>> nothing else has the nice asymmetrical fast decompression with such
>> effective compression (wavpack supports 705/768 but is woefully slow
>> on decompression and poorly supported). Mostly the sample rates would
>> be multiples of the common 44.1/48 sample rates so I expect
>> compression to be equally good with simple extrapolation to bigger
>> equivalent sized windows.
>
>
> In what setting are you thinking about playback? If this is a lab setting, 
> creating a small batch script to fetch the samplerate tag and passing it to a 
> playback program like ffplay doesn't seem a very big deal? If you want 
> playback on current existing, available hardware, augmenting the spec is not 
> going to work.

Definitely not a lab setting I'm afraid, I'm just experimenting at
home with my regular hi-fi gear. I'm just using clementine and roon
for playback and both load libFLAC so I guess I could create a custom
flac library to support a bastardised flac container.

Thanks,
Con
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Support for ultra-high sample rates?

[Martijn van Beurden]

Op do 25 jun. 2020 om 16:02 schreef Con Kolivas :

> The idea is to actually use it for playback, not just storage, and
> nothing else has the nice asymmetrical fast decompression with such
> effective compression (wavpack supports 705/768 but is woefully slow
> on decompression and poorly supported). Mostly the sample rates would
> be multiples of the common 44.1/48 sample rates so I expect
> compression to be equally good with simple extrapolation to bigger
> equivalent sized windows.
>

In what setting are you thinking about playback? If this is a lab setting,
creating a small batch script to fetch the samplerate tag and passing it to
a playback program like ffplay doesn't seem a very big deal? If you want
playback on current existing, available hardware, augmenting the spec is
not going to work.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Support for ultra-high sample rates?

[Adam Sampson]

Tor-Einar Jarnbjo  writes:

> Does it make sense to use FLAC to compress arbitrary analog data at
> very high sample rates as opposed to other general purpose compression
> algorithms?

As a data point on this, the ld-decode project uses FLAC to compress
40MHz samples of LaserDisc RF, which are a combination of FM composite
video, FM audio and CD-style EFM digital audio.

FLAC gets much better compression ratios than general-purpose
compression algorithms (typically about 55% the size of the 10-bit raw
input), and has the advantage that you can directly use audio tools for
visualising and manipulating samples.

-- 
Adam Sampson  
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC specification clarification

[Martijn van Beurden]

Op do 25 jun. 2020 om 14:09 schreef Stephen F. Booth :

> To me the real question is not whether that portion of the spec has been
> implemented by any existing encoders/decoders but whether the spec is
> broken (i.e. cannot be implemented as written).
>

We will never know for sure whether any existing encoder/decoder works this
way, but I can tell that two very influential ones, namely the reference
encoder and decoder, libFLAC and the ffmpeg encoder (previously known as
Flake) and decoder, do not implement negative shifts. As the licenses for
both are very open (libFLAC being BSD) I can imagine most proprietary
implementations are just straight copies.

I think the problem is not that there might be decoders that accept this or
encoders that (rarely) output this. I cannot say this for certain, but with
libFLAC and ffmpeg decoders not accepting this, I would say that the vast
majority of existing FLAC decoders does not accept this, and therefore
encoders should never output files with negative shifts, as most decoders
won't play such files.


> It's possible (generally/conceptually, not necessarily here) a negative
> shift value could be used to represent a left shift.
>

Yes, I think that was what was originally intended.


> However, I know very little about linear prediction and how coefficients
> are chosen and whether that makes sense
>

I will explain why using negative shifts has probably never any benefit.
Decoding LPC is rather simple to understand: to predict a sample, take the
first coefficient and multiply it by the previous (already decoded) sample,
add to that the second coefficient multiplied with the sample before that,
the third coefficient with the sample before etc. To predict sample 25 of a
block, the decoder has to sum this: LPC_1 * sample_24 + LPC_2 * sample_23 +
LPC_3 * sample_22 + LPC_4 * sample_21 etc. To finish the decoding of the
sample, the residual has to be added to the prediction. This residual is
stored and encoded separately.

These LPC coefficients are floating point numbers. Very often, when you sum
the coefficients (without multiplying them with samples) the results are
close to one, which means that the samples form a nicely correlated signal.
However, the FLAC format doesn't store floating point numbers, so it
quantizes them into integers to make sure no rounding errors can make the
result not-lossless.

How does this work? Assume we have a signal that can be predicted nicely (=
with efficiently encodable residual) with LPC coefficients 0.75; -0.375;
0.125; 0.5. To store these as integers, we multiply them by 8, and we get
7, -3, 1, 4. We also have to store a shift of +3 (2^3 = 8) so we get our
original LPC coefficients back.

For a "negative shift" to have a place, we would need the sum of the LPC
coefficients to between -0.5 and 0.5, which means it is a very quick
fade-out (which can only last a few samples). Probably one can synthesize
such signals, but looking at actual audio material, this does rarely
happen, especially with the larger blocksizes where non-fixed LPC
prediction shows its strengths.

Kind regards, Martijn van Beurden
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Support for ultra-high sample rates?

[Con Kolivas]

On Thu, 25 Jun 2020 at 23:11, Tor-Einar Jarnbjo  wrote:
>
> Isn't the FLAC encoder 'tuned' for the compression of audio data at common 
> sample rates anyway? Does it make sense to use FLAC to compress arbitrary 
> analog data at very high sample rates as opposed to other general purpose 
> compression algorithms?

The idea is to actually use it for playback, not just storage, and
nothing else has the nice asymmetrical fast decompression with such
effective compression (wavpack supports 705/768 but is woefully slow
on decompression and poorly supported). Mostly the sample rates would
be multiples of the common 44.1/48 sample rates so I expect
compression to be equally good with simple extrapolation to bigger
equivalent sized windows.

Thanks,
Con
>
> Tor
>
> Am 25.06.2020 um 14:49 schrieb Martijn van Beurden:
>
> Op di 2 jun. 2020 om 05:59 schreef Con Kolivas :
>>
>> It would be nice if the flac container was
>> extensible to any arbitrary value for research purposes.
>
>
> Probably not the answer that you were hoping for, but because it is only for 
> research purposes, why not store the samplerate outside of the container, or 
> in the comments as metadata? The FLAC encoder doesn't care what samplerate 
> your material is, it just stores it for easy playback. You can store 10MHz 
> information, tell the FLAC encoder it is 48kHz, and add a tag 
> samplerate=1000  or even samplerate=10MHz, whatever your processing 
> scripts accept.
>
> As you are clearly using FLAC for something it wasn't made for, that doesn't 
> seem like a very big workaround to me?
>
> Kind regards,
>
> Martijn van Beurden
>
> ___
> flac-dev mailing list
> flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
> ___
> flac-dev mailing list
> flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC specification clarification

[Stephen F. Booth]

To me the real question is not whether that portion of the spec has been
implemented by any existing encoders/decoders but whether the spec is
broken (i.e. cannot be implemented as written). I don't know the rationale
for making the LPC shift explicitly signed. In C a negative shift is
undefined and it does seem in FLAC__lpc_restore_signal() for example that
the LPC shift is used as the argument to a right shift operation. It's
possible (generally/conceptually, not necessarily here) a negative shift
value could be used to represent a left shift. However, I know very little
about linear prediction and how coefficients are chosen and whether that
makes sense. If it really is a design flaw in the spec then it makes sense
to change it or document that negative shifts are not supported by any
known implementation as you suggest.

Philosophically my objection to changing the spec based on lack of known
implementations is that it could be artificially limiting, for example the
same argument about breaking existing decoders could be made for 32-bit
samples sizes.


On Mon, Jun 22, 2020 at 1:33 AM Martijn van Beurden 
wrote:

> Yes, this is such a case. However, implementing this in a future
> encoder/decoder would break compatibility with most (likely all) existing
> decoders, and only in some very, very rare cases where the material is such
> that the encoder chooses to use negative shifts, which makes it even harder
> to troubleshoot. Furthermore, as this can only be used in very rare cases,
> there is no benefit from allowing this.
>
> Op vr 19 jun. 2020 om 18:03 schreef Stephen F. Booth :
>
>> Is this a case where something allowed by the specification isn't
>> implemented by the reference encoder/decoder (such as 25-32 bits per
>> sample) but could be in a different implementation? If so, I am not sure
>> whether it makes sense to change the specification based on the reference
>> implementation.
>>
>> Stephen
>>
>> On Wed, Jun 17, 2020 at 3:22 PM Martijn van Beurden 
>> wrote:
>>
>>> Hi all,
>>>
>>> When trying to better understand the way LPC exactly works, I stumbled
>>> upon something which, after some digging, was already reported and (partly)
>>> fixed: https://sourceforge.net/p/flac/bugs/424/
>>>
>>> Apparently, the FLAC specification has a LPC shift that can be both
>>> positive and negative, but the encoder specifically makes sure that only
>>> positive shifts are encoded and the decoder only accepts positive shifts.
>>> The ffmpeg FLAC encoder and decoder show the same behaviour.
>>>
>>> Now, the documentation in the source code is fixed, the documentation on
>>> the website (which I was looking at) isn't yet. The website format.html
>>> states: "Quantized linear predictor coefficient shift needed in bits (NOTE:
>>> this number is signed two's-complement)." The source code format.html says
>>> "Quantized linear predictor coefficient shift needed in bits (NOTE: this
>>> number is signed two's-complement; but, due to implementation details, must
>>> be non-negative)."
>>>
>>> I was thinking of submitting a patch to the FLAC website git to get the
>>> website format.html up-to-date (there have been more changes than just this
>>> one), but I feel the line above isn't clear enough. Maybe change it to
>>> something like this, to make the wording more similar to the rest of the
>>> specification
>>>
>>> Quantized linear predictor coefficient shift needed in bits (NOTE: these
>>> bits must be 0-0. Originally this was a signed integer, but
>>> negative shifts were never implemented).
>>>
>>> Or perhaps:
>>>
>>> Quantized linear predictor coefficient shift needed in bits (NOTE: First
>>> bit must be zero. Originally this was a signed integer, but negative shifts
>>> were never implemented).
>>>
>>> Any thoughts?
>>>
>>> Kind regards, Martijn van Beurden
>>> ___
>>> flac-dev mailing list
>>> flac-dev@xiph.org
>>> http://lists.xiph.org/mailman/listinfo/flac-dev
>>>
>>
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Support for ultra-high sample rates?

[Tor-Einar Jarnbjo]

Isn't the FLAC encoder 'tuned' for the compression of audio data at 
common sample rates anyway? Does it make sense to use FLAC to compress 
arbitrary analog data at very high sample rates as opposed to other 
general purpose compression algorithms?


Tor

Am 25.06.2020 um 14:49 schrieb Martijn van Beurden:
Op di 2 jun. 2020 om 05:59 schreef Con Kolivas >:


It would be nice if the flac container was
extensible to any arbitrary value for research purposes.


Probably not the answer that you were hoping for, but because it is 
only for research purposes, why not store the samplerate outside of 
the container, or in the comments as metadata? The FLAC encoder 
doesn't care what samplerate your material is, it just stores it for 
easy playback. You can store 10MHz information, tell the FLAC encoder 
it is 48kHz, and add a tag samplerate=1000  or even 
samplerate=10MHz, whatever your processing scripts accept.


As you are clearly using FLAC for something it wasn't made for, that 
doesn't seem like a very big workaround to me?


Kind regards,

Martijn van Beurden

___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Support for ultra-high sample rates?

[Martijn van Beurden]

Op di 2 jun. 2020 om 05:59 schreef Con Kolivas :

> It would be nice if the flac container was
> extensible to any arbitrary value for research purposes.
>

Probably not the answer that you were hoping for, but because it is only
for research purposes, why not store the samplerate outside of the
container, or in the comments as metadata? The FLAC encoder doesn't care
what samplerate your material is, it just stores it for easy playback. You
can store 10MHz information, tell the FLAC encoder it is 48kHz, and add a
tag samplerate=1000  or even samplerate=10MHz, whatever your processing
scripts accept.

As you are clearly using FLAC for something it wasn't made for, that
doesn't seem like a very big workaround to me?

Kind regards,

Martijn van Beurden
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev