[FFmpeg-devel] [PATCH] libavcodec/flacenc: Enable sample rates > 655350 Hz

Martijn van Beurden mvanb1 at gmail.com
Mon Oct 31 20:33:41 EET 2022


Op ma 31 okt. 2022 om 17:58 schreef Derek Buitenhuis
<derek.buitenhuis at gmail.com>:
>
> It is interesting that the IETF RFC and the Xiph spec disagree on whether this is allowed.
>

The Xiph spec also says the IETF spec is better, and it remains as
historical reference and overview :)

> The Xiph spec says:
>
>     Sample rate in Hz. Though 20 bits are available, the maximum sample rate is limited by the
>     structure of frame headers to 655350Hz. Also, a value of 0 is invalid.
>
> The RFC just says:
>
>    Sample rate in Hz.
>

The spec as it is on the FLAC website (which is being "preserved") is
wrong. I don't know how this came to be, I think it was at first
poorly worded and later incorrectly fixed. See this commit:
https://github.com/xiph/flac/commit/96534bb5f35eb9c2f6f393dc470625e9c74df1a5
The text as it was before that commit doesn't make any sense, the text
as it is after the commit is not correct either.

The issue here is that FLAC has a sample rate in the streaminfo
metadata block, at the very start of the file. That one can
accommodate sample rates up to 2^20-1. The frame headers repeat the
sample rate every frame and can only accommodate up to 655350Hz, but
they can also reference the streaminfo metadata block. Because of the
possibility to reference that 20 bit number, it is possible to store
sample rates up to 1048575Hz. You can see this patch only touches the
encoder: the FFmpeg decoder has already been equipped to deal with
this since its inception in 2004.

There is some kind of limitation to sample rates above 655350Hz, or
samplerates between 65535Hz and 655350Hz that are not a multiple of 10
though: a FLAC file with such a sample rate cannot be multicast,
because a decoder receiving a multicast stream does not receive the
streaminfo metadata block, and thus cannot use it to figure out the
correct sample rate.

Please let me know when this explanation falls short.

Kind regards, Martijn van Beurden


More information about the ffmpeg-devel mailing list