"Frame" is an MPEG term, which is not only unintuitive but also
overloaded with different meaning by other codecs (e.g. FLAC).
Therefore, use the standard term Sample for the central audio structure.
The class is also extracted to its own file, because it's becoming quite
large. Bundling these two changes means not distributing similar
modifications (changing names and paths) across commits.
Co-authored-by: kleines Filmröllchen <malu.bertsch@gmail.com>
They're mostly used in literal random data, so it isn't like
there is a high demand for it, but it's cool to have more complete
implementation anyway. :^)
All audio applications (aplay, Piano, Sound Player) respect the ability
of the system to have theoretically any sample rate. Therefore, they
resample their own audio into the system sample rate.
LibAudio previously had its loaders resample their own audio, even
though they expose their sample rate. This is now changed. The loaders
output audio data in their file's sample rate, which the user has to
query and resample appropriately. Resampling code from Buffer, WavLoader
and FlacLoader is removed.
Note that these applications only check the sample rate at startup,
which is reasonable (the user has to restart applications when changing
the sample rate). Fully dynamic adaptation could both lead to errors and
will require another IPC interface. This seems to be enough for now.
FlacLoader initialized, but never used its resampler; this is now fixed
and all subframes are resampled before decorrelation occurs. FLAC files
with non-44100-Hz sample rates now play properly.
When computing sample values from a linear predictor, the repeated
multiplication and addition can lead to very large values that may
overflow a 32-bit integer. This was never discovered with 16-bit FLAC
test files used to create and validate the first version of the FLAC
loader. However, 24-bit audio, especially with large LPC shifts, will
regularly exceed and overflow i32. Therefore, we now use 64 bits
temporarily. If the resulting value is too large for 32 bits, something
else has gone wrong :^)
This fixes playback noise on 24-bit FLACs.
The FLAC samples are signed, so we need to rescale them not by their bit
depth, but by half of the bit depth. For example, a 24-bit sample
extends from -2^23 to 2^23-1, and therefore needs to be rescaled by 2^23
to conform to the [-1, 1] double sample range.
Playing a lossy flac file resulted in hearing something
you'd not like to play. Instead of your lovely bass, you had sounds
as if you put a CD-ROM disc to a CD player.
It turned out that the size for making signed values was too big,
making all the values unsigned.
I've used lossyWav[1] (the posix port[2] to be exact)
to generate such files.
[1]: https://wiki.hydrogenaud.io/index.php?title=LossyWAV
[2]: https://github.com/MoSal/lossywav-for-posix
Prior this change, decoding fixed subframes produced "unpleasant
crackling noices".
While the type doesn't appear so often when using the default settings,
encoding files in flac(1) with --fast option uses fixed subframes
almost every time.
This also applies the logic to the constant subframes,
which isn't so important, as the type is generally for the silence,
but let's use it as well to avoid inconsistency.
Before this change the file stream was generated two times:
one time in the parse_header(), and another time for the whole class
in the constructor.
The previous commit moved the m_stream initialization before
executing the parse_header function, so we can now reuse that here.
Before this change opening the file in the system resulted in crash
caused by assertion saying:
SoundPlayer(32:32): ASSERTION FAILED: m_ptr
../.././AK/OwnPtr.h:139
[#0 SoundPlayer(32:32)]: Terminating SoundPlayer(32) due to signal 6
[#0 FinalizerTask(4:4)]: 0xdeadc0de
The issue was that 845d403b8c started
using m_stream in the parse_header() function, but that variable wasn't
initialized if the Loader plugin was created using a file path
(which is used everywhere except for the fuzz testing),
resulting in a crash mentioned above.
The FlacLoader already has numerous checks for invalid data reads and
for invalid stream states, but it never actually handles the stream
errors on the stream object. By handling them properly we can actually
run FuzzFlacLoader for longer than a few seconds before it hits the
first assertion :^).
This fixes stucking in a loop at the end of the file, as
(a) custom block sizes are usually placed there, as the remaining
size might not be simply calculated as a power of two, and
(b) the number of bytes to read was incorrect (the program said
the block size was 32525, where flac -a said it's actually 3200).
Unfortunately, I couldn't trigger the bug for the sample rates,
so it may be not true, but I'd doubt it, giving the fact that flac
almost everywhere uses big endian numbers.
The problem here was that the multi-byte UTF-8 encoded characters
were taking one byte too much, misaligning the data completely
and eventually crashing the program on the 128th frame.
This change reduces the for loop by one, as it has been already
calculated from the start_byte variable.
AK's version should see better inlining behaviors, than the LibM one.
We avoid mixed usage for now though.
Also clean up some stale math includes and improper floatingpoint usage.
This fixes an crash caused by using the type from
FlacSubframeHeader::order (unsigned 8-bit), which after overflowing
the integer, converting it back to u32, and decrementing by one
resulted in accessing an array waaay out of bounds.
This commit adds a loader for the FLAC audio codec, the Free Lossless
Audio codec by the Xiph.Org foundation. LibAudio will automatically
read and parse FLAC files, so users do not need to adjust.
This implementation is bare-bones and needs to be improved upon.
There are many bugs, verbatim subframes and any kind of seeking is
not supported. However, stereo files exported by libavcodec on
highest compression setting seem to work well.
