2021-06-25 13:54:14 +02:00
/*
* Copyright ( c ) 2021 , kleines Filmröllchen < malu . bertsch @ gmail . com >
*
* SPDX - License - Identifier : BSD - 2 - Clause
*/
# include <AK/Debug.h>
# include <AK/FlyString.h>
# include <AK/Format.h>
2021-07-17 18:29:28 +02:00
# include <AK/Math.h>
2021-08-01 05:42:09 -06:00
# include <AK/ScopeGuard.h>
2021-12-16 23:18:49 +01:00
# include <AK/StdLibExtras.h>
2021-06-25 13:54:14 +02:00
# include <AK/String.h>
# include <AK/StringBuilder.h>
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
# include <AK/Try.h>
# include <AK/UFixedBigInt.h>
# include <LibAudio/Buffer.h>
# include <LibAudio/FlacLoader.h>
# include <LibAudio/FlacTypes.h>
# include <LibAudio/LoaderError.h>
2021-06-25 13:54:14 +02:00
# include <LibCore/File.h>
namespace Audio {
2021-11-11 00:55:02 +01:00
FlacLoaderPlugin : : FlacLoaderPlugin ( StringView path )
2021-06-25 13:54:14 +02:00
: m_file ( Core : : File : : construct ( path ) )
{
if ( ! m_file - > open ( Core : : OpenMode : : ReadOnly ) ) {
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
m_error = LoaderError { String : : formatted ( " Can't open file: {} " , m_file - > error_string ( ) ) } ;
2021-06-25 13:54:14 +02:00
return ;
}
2021-12-16 23:18:49 +01:00
auto maybe_stream = Buffered < Core : : InputFileStream , FLAC_BUFFER_SIZE > { MUST ( Core : : File : : open ( path , Core : : OpenMode : : ReadOnly ) ) } ;
m_stream = make < FlacInputStream < FLAC_BUFFER_SIZE > > ( move ( maybe_stream ) ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
if ( ! m_stream )
m_error = LoaderError { " Can't open file stream " } ;
2021-06-25 13:54:14 +02:00
}
FlacLoaderPlugin : : FlacLoaderPlugin ( const ByteBuffer & buffer )
{
2021-12-16 23:18:49 +01:00
m_stream = make < FlacInputStream < FLAC_BUFFER_SIZE > > ( InputMemoryStream ( buffer ) ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
if ( ! m_stream )
m_error = LoaderError { " Can't open memory stream " } ;
2021-06-25 13:54:14 +02:00
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
MaybeLoaderError FlacLoaderPlugin : : initialize ( )
2021-06-25 13:54:14 +02:00
{
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
if ( m_error . has_value ( ) )
return m_error . release_value ( ) ;
TRY ( parse_header ( ) ) ;
TRY ( reset ( ) ) ;
return { } ;
2021-06-25 13:54:14 +02:00
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
MaybeLoaderError FlacLoaderPlugin : : parse_header ( )
2021-06-25 13:54:14 +02:00
{
InputBitStream bit_input = [ & ] ( ) - > InputBitStream {
if ( m_file ) {
2021-12-16 23:18:49 +01:00
return InputBitStream ( m_stream - > get < Buffered < Core : : InputFileStream , FLAC_BUFFER_SIZE > > ( ) ) ;
2021-06-25 13:54:14 +02:00
}
return InputBitStream ( m_stream - > get < InputMemoryStream > ( ) ) ;
} ( ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
ScopeGuard handle_all_errors ( [ & bit_input , this ] {
m_stream - > handle_any_error ( ) ;
bit_input . handle_any_error ( ) ;
} ) ;
// A mixture of VERIFY and the non-crashing TRY().
# define FLAC_VERIFY(check, category, msg) \
do { \
if ( ! ( check ) ) { \
return LoaderError { category , static_cast < size_t > ( m_data_start_location ) , String : : formatted ( " FLAC header: {} " , msg ) } ; \
} \
2021-06-25 13:54:14 +02:00
} while ( 0 )
// Magic number
2021-11-15 22:27:28 +01:00
u32 flac = static_cast < u32 > ( bit_input . read_bits_big_endian ( 32 ) ) ;
2021-06-25 13:54:14 +02:00
m_data_start_location + = 4 ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( flac = = 0x664C6143 , LoaderError : : Category : : Format , " Magic number must be 'flaC' " ) ; // "flaC"
2021-06-25 13:54:14 +02:00
// Receive the streaminfo block
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
auto streaminfo = TRY ( next_meta_block ( bit_input ) ) ;
FLAC_VERIFY ( streaminfo . type = = FlacMetadataBlockType : : STREAMINFO , LoaderError : : Category : : Format , " First block must be STREAMINFO " ) ;
2021-06-25 13:54:14 +02:00
InputMemoryStream streaminfo_data_memory ( streaminfo . data . bytes ( ) ) ;
InputBitStream streaminfo_data ( streaminfo_data_memory ) ;
2021-08-01 05:42:09 -06:00
ScopeGuard clear_streaminfo_errors ( [ & streaminfo_data ] { streaminfo_data . handle_any_error ( ) ; } ) ;
2021-06-25 13:54:14 +02:00
// STREAMINFO block
2021-11-15 22:27:28 +01:00
m_min_block_size = static_cast < u16 > ( streaminfo_data . read_bits_big_endian ( 16 ) ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( m_min_block_size > = 16 , LoaderError : : Category : : Format , " Minimum block size must be 16 " ) ;
2021-11-15 22:27:28 +01:00
m_max_block_size = static_cast < u16 > ( streaminfo_data . read_bits_big_endian ( 16 ) ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( m_max_block_size > = 16 , LoaderError : : Category : : Format , " Maximum block size " ) ;
2021-11-15 22:27:28 +01:00
m_min_frame_size = static_cast < u32 > ( streaminfo_data . read_bits_big_endian ( 24 ) ) ;
m_max_frame_size = static_cast < u32 > ( streaminfo_data . read_bits_big_endian ( 24 ) ) ;
m_sample_rate = static_cast < u32 > ( streaminfo_data . read_bits_big_endian ( 20 ) ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( m_sample_rate < = 655350 , LoaderError : : Category : : Format , " Sample rate " ) ;
m_num_channels = static_cast < u8 > ( streaminfo_data . read_bits_big_endian ( 3 ) ) + 1 ; // 0 = one channel
2021-06-25 13:54:14 +02:00
2021-11-15 22:27:28 +01:00
u8 bits_per_sample = static_cast < u8 > ( streaminfo_data . read_bits_big_endian ( 5 ) ) + 1 ;
2021-06-25 13:54:14 +02:00
if ( bits_per_sample = = 8 ) {
// FIXME: Signed/Unsigned issues?
m_sample_format = PcmSampleFormat : : Uint8 ;
} else if ( bits_per_sample = = 16 ) {
m_sample_format = PcmSampleFormat : : Int16 ;
} else if ( bits_per_sample = = 24 ) {
m_sample_format = PcmSampleFormat : : Int24 ;
} else if ( bits_per_sample = = 32 ) {
m_sample_format = PcmSampleFormat : : Int32 ;
} else {
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( false , LoaderError : : Category : : Format , " Sample bit depth invalid " ) ;
2021-06-25 13:54:14 +02:00
}
2021-11-15 22:27:28 +01:00
m_total_samples = static_cast < u64 > ( streaminfo_data . read_bits_big_endian ( 36 ) ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( m_total_samples > 0 , LoaderError : : Category : : Format , " Number of samples is zero " ) ;
2021-06-25 13:54:14 +02:00
// Parse checksum into a buffer first
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
[[maybe_unused]] u128 md5_checksum ;
auto md5_bytes_read = streaminfo_data . read ( md5_checksum . bytes ( ) ) ;
FLAC_VERIFY ( md5_bytes_read = = md5_checksum . my_size ( ) , LoaderError : : Category : : IO , " MD5 Checksum size " ) ;
md5_checksum . bytes ( ) . copy_to ( { m_md5_checksum , sizeof ( m_md5_checksum ) } ) ;
2021-06-25 13:54:14 +02:00
// Parse other blocks
// TODO: For a simple first implementation, all other blocks are skipped as allowed by the FLAC specification.
// Especially the SEEKTABLE block may become useful in a more sophisticated version.
[[maybe_unused]] u16 meta_blocks_parsed = 1 ;
[[maybe_unused]] u16 total_meta_blocks = meta_blocks_parsed ;
FlacRawMetadataBlock block = streaminfo ;
while ( ! block . is_last_block ) {
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
block = TRY ( next_meta_block ( bit_input ) ) ;
2021-06-25 13:54:14 +02:00
+ + total_meta_blocks ;
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( ! m_stream - > handle_any_error ( ) , LoaderError : : Category : : IO , " Stream " ) ;
2021-08-01 05:42:09 -06:00
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
dbgln_if ( AFLACLOADER_DEBUG , " Parsed FLAC header: blocksize {}-{}{}, framesize {}-{}, {}Hz, {}bit, {} channels, {} samples total ({:.2f}s), MD5 {}, data start at {:x} bytes, {} headers total (skipped {}) " , m_min_block_size , m_max_block_size , is_fixed_blocksize_stream ( ) ? " (constant) " : " " , m_min_frame_size , m_max_frame_size , m_sample_rate , pcm_bits_per_sample ( m_sample_format ) , m_num_channels , m_total_samples , static_cast < double > ( m_total_samples ) / static_cast < double > ( m_sample_rate ) , md5_checksum , m_data_start_location , total_meta_blocks , total_meta_blocks - meta_blocks_parsed ) ;
2021-06-25 13:54:14 +02:00
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
return { } ;
2021-06-25 13:54:14 +02:00
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
ErrorOr < FlacRawMetadataBlock , LoaderError > FlacLoaderPlugin : : next_meta_block ( InputBitStream & bit_input )
2021-06-25 13:54:14 +02:00
{
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
# define CHECK_IO_ERROR() \
do { \
if ( bit_input . handle_any_error ( ) ) \
return LoaderError { LoaderError : : Category : : IO , " Read error " } ; \
2021-06-25 13:54:14 +02:00
} while ( 0 )
bool is_last_block = bit_input . read_bit_big_endian ( ) ;
CHECK_IO_ERROR ( ) ;
// The block type enum constants agree with the specification
FlacMetadataBlockType type = ( FlacMetadataBlockType ) bit_input . read_bits_big_endian ( 7 ) ;
CHECK_IO_ERROR ( ) ;
m_data_start_location + = 1 ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( type ! = FlacMetadataBlockType : : INVALID , LoaderError : : Category : : Format , " Invalid metadata block " ) ;
2021-06-25 13:54:14 +02:00
2021-11-15 22:27:28 +01:00
u32 block_length = static_cast < u32 > ( bit_input . read_bits_big_endian ( 24 ) ) ;
2021-06-25 13:54:14 +02:00
m_data_start_location + = 3 ;
CHECK_IO_ERROR ( ) ;
2021-09-06 03:29:52 +04:30
auto block_data_result = ByteBuffer : : create_uninitialized ( block_length ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( block_data_result . has_value ( ) , LoaderError : : Category : : IO , " Out of memory " ) ;
2021-09-06 03:29:52 +04:30
auto block_data = block_data_result . release_value ( ) ;
2021-06-25 13:54:14 +02:00
// Reads exactly the bytes necessary into the Bytes container
bit_input . read ( block_data ) ;
m_data_start_location + = block_length ;
CHECK_IO_ERROR ( ) ;
return FlacRawMetadataBlock {
is_last_block ,
type ,
block_length ,
block_data ,
} ;
# undef CHECK_IO_ERROR
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
# undef FLAC_VERIFY
2021-06-25 13:54:14 +02:00
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
MaybeLoaderError FlacLoaderPlugin : : reset ( )
2021-06-25 13:54:14 +02:00
{
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
TRY ( seek ( m_data_start_location ) ) ;
2021-06-25 13:54:14 +02:00
m_current_frame . clear ( ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
return { } ;
2021-06-25 13:54:14 +02:00
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
MaybeLoaderError FlacLoaderPlugin : : seek ( const int position )
2021-06-25 13:54:14 +02:00
{
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
if ( ! m_stream - > seek ( position ) )
return LoaderError { LoaderError : : IO , m_loaded_samples , String : : formatted ( " Invalid seek position {} " , position ) } ;
return { } ;
2021-06-25 13:54:14 +02:00
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
LoaderSamples FlacLoaderPlugin : : get_more_samples ( size_t max_bytes_to_read_from_input )
2021-06-25 13:54:14 +02:00
{
2021-09-23 21:16:03 +02:00
Vector < Sample > samples ;
2021-11-15 22:27:28 +01:00
ssize_t remaining_samples = static_cast < ssize_t > ( m_total_samples - m_loaded_samples ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
if ( remaining_samples < = 0 )
return Buffer : : create_empty ( ) ;
2021-07-22 16:56:05 +02:00
size_t samples_to_read = min ( max_bytes_to_read_from_input , remaining_samples ) ;
2021-10-03 19:01:44 +02:00
samples . ensure_capacity ( samples_to_read ) ;
2021-07-22 16:56:05 +02:00
while ( samples_to_read > 0 ) {
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
if ( ! m_current_frame . has_value ( ) )
TRY ( next_frame ( ) ) ;
2021-10-03 19:01:44 +02:00
// Do a full vector extend if possible
if ( m_current_frame_data . size ( ) < = samples_to_read ) {
samples_to_read - = m_current_frame_data . size ( ) ;
samples . extend ( move ( m_current_frame_data ) ) ;
m_current_frame_data . clear ( ) ;
2021-06-25 13:54:14 +02:00
m_current_frame . clear ( ) ;
2021-10-03 19:01:44 +02:00
} else {
samples . unchecked_append ( m_current_frame_data . data ( ) , samples_to_read ) ;
m_current_frame_data . remove ( 0 , samples_to_read ) ;
if ( m_current_frame_data . size ( ) = = 0 ) {
m_current_frame . clear ( ) ;
}
samples_to_read = 0 ;
2021-06-25 13:54:14 +02:00
}
}
2021-07-22 15:41:18 +02:00
m_loaded_samples + = samples . size ( ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
auto maybe_buffer = Buffer : : create_with_samples ( move ( samples ) ) ;
if ( maybe_buffer . is_error ( ) )
return LoaderError { LoaderError : : Category : : Internal , m_loaded_samples , " Couldn't allocate sample buffer " } ;
return maybe_buffer . release_value ( ) ;
2021-06-25 13:54:14 +02:00
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
MaybeLoaderError FlacLoaderPlugin : : next_frame ( )
2021-06-25 13:54:14 +02:00
{
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
# define FLAC_VERIFY(check, category, msg) \
do { \
if ( ! ( check ) ) { \
return LoaderError { category , static_cast < size_t > ( m_current_sample_or_frame ) , String : : formatted ( " FLAC header: {} " , msg ) } ; \
} \
2021-06-25 13:54:14 +02:00
} while ( 0 )
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
InputBitStream bit_stream = m_stream - > bit_stream ( ) ;
2021-06-25 13:54:14 +02:00
// TODO: Check the CRC-16 checksum (and others) by keeping track of read data
// FLAC frame sync code starts header
2021-11-15 22:27:28 +01:00
u16 sync_code = static_cast < u16 > ( bit_stream . read_bits_big_endian ( 14 ) ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( sync_code = = 0b11111111111110 , LoaderError : : Category : : Format , " Sync code " ) ;
2021-06-25 13:54:14 +02:00
bool reserved_bit = bit_stream . read_bit_big_endian ( ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( reserved_bit = = 0 , LoaderError : : Category : : Format , " Reserved frame header bit " ) ;
2021-06-25 13:54:14 +02:00
[[maybe_unused]] bool blocking_strategy = bit_stream . read_bit_big_endian ( ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
u32 sample_count = TRY ( convert_sample_count_code ( static_cast < u8 > ( bit_stream . read_bits_big_endian ( 4 ) ) ) ) ;
2021-06-25 13:54:14 +02:00
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
u32 frame_sample_rate = TRY ( convert_sample_rate_code ( static_cast < u8 > ( bit_stream . read_bits_big_endian ( 4 ) ) ) ) ;
2021-06-25 13:54:14 +02:00
2021-11-15 22:27:28 +01:00
u8 channel_type_num = static_cast < u8 > ( bit_stream . read_bits_big_endian ( 4 ) ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( channel_type_num < 0b1011 , LoaderError : : Format , " Channel assignment " ) ;
2021-06-25 13:54:14 +02:00
FlacFrameChannelType channel_type = ( FlacFrameChannelType ) channel_type_num ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
PcmSampleFormat bit_depth = TRY ( convert_bit_depth_code ( static_cast < u8 > ( bit_stream . read_bits_big_endian ( 3 ) ) ) ) ;
2021-06-25 13:54:14 +02:00
reserved_bit = bit_stream . read_bit_big_endian ( ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FLAC_VERIFY ( reserved_bit = = 0 , LoaderError : : Category : : Format , " Reserved frame header end bit " ) ;
2021-06-25 13:54:14 +02:00
// FIXME: sample number can be 8-56 bits, frame number can be 8-48 bits
m_current_sample_or_frame = read_utf8_char ( bit_stream ) ;
// Conditional header variables
if ( sample_count = = FLAC_BLOCKSIZE_AT_END_OF_HEADER_8 ) {
2021-11-15 22:27:28 +01:00
sample_count = static_cast < u32 > ( bit_stream . read_bits_big_endian ( 8 ) ) + 1 ;
2021-06-25 13:54:14 +02:00
} else if ( sample_count = = FLAC_BLOCKSIZE_AT_END_OF_HEADER_16 ) {
2021-11-15 22:27:28 +01:00
sample_count = static_cast < u32 > ( bit_stream . read_bits_big_endian ( 16 ) ) + 1 ;
2021-06-25 13:54:14 +02:00
}
if ( frame_sample_rate = = FLAC_SAMPLERATE_AT_END_OF_HEADER_8 ) {
2021-11-15 22:27:28 +01:00
frame_sample_rate = static_cast < u32 > ( bit_stream . read_bits_big_endian ( 8 ) ) * 1000 ;
2021-06-25 13:54:14 +02:00
} else if ( frame_sample_rate = = FLAC_SAMPLERATE_AT_END_OF_HEADER_16 ) {
2021-11-15 22:27:28 +01:00
frame_sample_rate = static_cast < u32 > ( bit_stream . read_bits_big_endian ( 16 ) ) ;
2021-06-25 13:54:14 +02:00
} else if ( frame_sample_rate = = FLAC_SAMPLERATE_AT_END_OF_HEADER_16X10 ) {
2021-11-15 22:27:28 +01:00
frame_sample_rate = static_cast < u32 > ( bit_stream . read_bits_big_endian ( 16 ) ) * 10 ;
2021-06-25 13:54:14 +02:00
}
// TODO: check header checksum, see above
2021-11-15 22:27:28 +01:00
[[maybe_unused]] u8 checksum = static_cast < u8 > ( bit_stream . read_bits ( 8 ) ) ;
2021-06-25 13:54:14 +02:00
dbgln_if ( AFLACLOADER_DEBUG , " Frame: {} samples, {}bit {}Hz, channeltype {:x}, {} number {}, header checksum {} " , sample_count , pcm_bits_per_sample ( bit_depth ) , frame_sample_rate , channel_type_num , blocking_strategy ? " sample " : " frame " , m_current_sample_or_frame , checksum ) ;
m_current_frame = FlacFrameHeader {
sample_count ,
frame_sample_rate ,
channel_type ,
bit_depth ,
} ;
u8 subframe_count = frame_channel_type_to_channel_count ( channel_type ) ;
Vector < Vector < i32 > > current_subframes ;
current_subframes . ensure_capacity ( subframe_count ) ;
for ( u8 i = 0 ; i < subframe_count ; + + i ) {
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
FlacSubframeHeader new_subframe = TRY ( next_subframe_header ( bit_stream , i ) ) ;
Vector < i32 > subframe_samples = TRY ( parse_subframe ( new_subframe , bit_stream ) ) ;
2021-06-25 13:54:14 +02:00
current_subframes . append ( move ( subframe_samples ) ) ;
}
bit_stream . align_to_byte_boundary ( ) ;
// TODO: check checksum, see above
2021-11-15 22:27:28 +01:00
[[maybe_unused]] u16 footer_checksum = static_cast < u16 > ( bit_stream . read_bits_big_endian ( 16 ) ) ;
2021-06-25 13:54:14 +02:00
2021-11-15 22:27:28 +01:00
Vector < i32 > left ;
Vector < i32 > right ;
2021-06-25 13:54:14 +02:00
switch ( channel_type ) {
case FlacFrameChannelType : : Mono :
left = right = current_subframes [ 0 ] ;
break ;
case FlacFrameChannelType : : Stereo :
// TODO mix together surround channels on each side?
case FlacFrameChannelType : : StereoCenter :
case FlacFrameChannelType : : Surround4p0 :
case FlacFrameChannelType : : Surround5p0 :
case FlacFrameChannelType : : Surround5p1 :
case FlacFrameChannelType : : Surround6p1 :
case FlacFrameChannelType : : Surround7p1 :
left = current_subframes [ 0 ] ;
right = current_subframes [ 1 ] ;
break ;
case FlacFrameChannelType : : LeftSideStereo :
// channels are left (0) and side (1)
left = current_subframes [ 0 ] ;
right . ensure_capacity ( left . size ( ) ) ;
for ( size_t i = 0 ; i < left . size ( ) ; + + i ) {
// right = left - side
right . unchecked_append ( left [ i ] - current_subframes [ 1 ] [ i ] ) ;
}
break ;
case FlacFrameChannelType : : RightSideStereo :
// channels are side (0) and right (1)
right = current_subframes [ 1 ] ;
left . ensure_capacity ( right . size ( ) ) ;
for ( size_t i = 0 ; i < right . size ( ) ; + + i ) {
// left = right + side
left . unchecked_append ( right [ i ] + current_subframes [ 0 ] [ i ] ) ;
}
break ;
case FlacFrameChannelType : : MidSideStereo :
// channels are mid (0) and side (1)
left . ensure_capacity ( current_subframes [ 0 ] . size ( ) ) ;
right . ensure_capacity ( current_subframes [ 0 ] . size ( ) ) ;
for ( size_t i = 0 ; i < current_subframes [ 0 ] . size ( ) ; + + i ) {
i64 mid = current_subframes [ 0 ] [ i ] ;
i64 side = current_subframes [ 1 ] [ i ] ;
mid * = 2 ;
// prevent integer division errors
left . unchecked_append ( static_cast < i32 > ( ( mid + side ) / 2 ) ) ;
right . unchecked_append ( static_cast < i32 > ( ( mid - side ) / 2 ) ) ;
}
break ;
}
VERIFY ( left . size ( ) = = right . size ( ) ) ;
2021-08-16 22:01:26 +02:00
double sample_rescale = static_cast < double > ( 1 < < ( pcm_bits_per_sample ( m_current_frame - > bit_depth ) - 1 ) ) ;
2021-06-25 13:54:14 +02:00
dbgln_if ( AFLACLOADER_DEBUG , " Sample rescaled from {} bits: factor {:.1f} " , pcm_bits_per_sample ( m_current_frame - > bit_depth ) , sample_rescale ) ;
m_current_frame_data . clear_with_capacity ( ) ;
m_current_frame_data . ensure_capacity ( left . size ( ) ) ;
// zip together channels
for ( size_t i = 0 ; i < left . size ( ) ; + + i ) {
2021-09-23 21:16:03 +02:00
Sample frame = { left [ i ] / sample_rescale , right [ i ] / sample_rescale } ;
2021-06-25 13:54:14 +02:00
m_current_frame_data . unchecked_append ( frame ) ;
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
return { } ;
# undef FLAC_VERIFY
2021-06-25 13:54:14 +02:00
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
ErrorOr < u32 , LoaderError > FlacLoaderPlugin : : convert_sample_count_code ( u8 sample_count_code )
2021-06-25 13:54:14 +02:00
{
// single codes
switch ( sample_count_code ) {
case 0 :
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
return LoaderError { LoaderError : : Category : : Format , static_cast < size_t > ( m_current_sample_or_frame ) , " Reserved block size " } ;
2021-06-25 13:54:14 +02:00
case 1 :
return 192 ;
case 6 :
return FLAC_BLOCKSIZE_AT_END_OF_HEADER_8 ;
case 7 :
return FLAC_BLOCKSIZE_AT_END_OF_HEADER_16 ;
}
if ( sample_count_code > = 2 & & sample_count_code < = 5 ) {
2021-07-17 18:29:28 +02:00
return 576 * AK : : exp2 ( sample_count_code - 2 ) ;
2021-06-25 13:54:14 +02:00
}
2021-07-17 18:29:28 +02:00
return 256 * AK : : exp2 ( sample_count_code - 8 ) ;
2021-06-25 13:54:14 +02:00
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
ErrorOr < u32 , LoaderError > FlacLoaderPlugin : : convert_sample_rate_code ( u8 sample_rate_code )
2021-06-25 13:54:14 +02:00
{
switch ( sample_rate_code ) {
case 0 :
return m_sample_rate ;
case 1 :
return 88200 ;
case 2 :
return 176400 ;
case 3 :
return 192000 ;
case 4 :
return 8000 ;
case 5 :
return 16000 ;
case 6 :
return 22050 ;
case 7 :
return 24000 ;
case 8 :
return 32000 ;
case 9 :
return 44100 ;
case 10 :
return 48000 ;
case 11 :
return 96000 ;
case 12 :
return FLAC_SAMPLERATE_AT_END_OF_HEADER_8 ;
case 13 :
return FLAC_SAMPLERATE_AT_END_OF_HEADER_16 ;
case 14 :
return FLAC_SAMPLERATE_AT_END_OF_HEADER_16X10 ;
default :
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
return LoaderError { LoaderError : : Category : : Format , static_cast < size_t > ( m_current_sample_or_frame ) , " Invalid sample rate code " } ;
2021-06-25 13:54:14 +02:00
}
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
ErrorOr < PcmSampleFormat , LoaderError > FlacLoaderPlugin : : convert_bit_depth_code ( u8 bit_depth_code )
2021-06-25 13:54:14 +02:00
{
switch ( bit_depth_code ) {
case 0 :
return m_sample_format ;
case 1 :
return PcmSampleFormat : : Uint8 ;
case 4 :
return PcmSampleFormat : : Int16 ;
case 6 :
return PcmSampleFormat : : Int24 ;
case 3 :
case 7 :
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
return LoaderError { LoaderError : : Category : : Format , static_cast < size_t > ( m_current_sample_or_frame ) , " Reserved sample size " } ;
2021-06-25 13:54:14 +02:00
default :
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
return LoaderError { LoaderError : : Category : : Format , static_cast < size_t > ( m_current_sample_or_frame ) , String : : formatted ( " Unsupported sample size {} " , bit_depth_code ) } ;
2021-06-25 13:54:14 +02:00
}
}
u8 frame_channel_type_to_channel_count ( FlacFrameChannelType channel_type )
{
if ( channel_type < = 7 )
return channel_type + 1 ;
return 2 ;
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
ErrorOr < FlacSubframeHeader , LoaderError > FlacLoaderPlugin : : next_subframe_header ( InputBitStream & bit_stream , u8 channel_index )
2021-06-25 13:54:14 +02:00
{
2021-11-15 22:27:28 +01:00
u8 bits_per_sample = static_cast < u16 > ( pcm_bits_per_sample ( m_current_frame - > bit_depth ) ) ;
2021-06-25 13:54:14 +02:00
// For inter-channel correlation, the side channel needs an extra bit for its samples
switch ( m_current_frame - > channels ) {
case LeftSideStereo :
case MidSideStereo :
if ( channel_index = = 1 ) {
+ + bits_per_sample ;
}
break ;
case RightSideStereo :
if ( channel_index = = 0 ) {
+ + bits_per_sample ;
}
break ;
// "normal" channel types
default :
break ;
}
// zero-bit padding
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
if ( bit_stream . read_bit_big_endian ( ) ! = 0 )
return LoaderError { LoaderError : : Category : : Format , static_cast < size_t > ( m_current_sample_or_frame ) , " Zero bit padding " } ;
2021-06-25 13:54:14 +02:00
// subframe type (encoding)
2021-11-15 22:27:28 +01:00
u8 subframe_code = static_cast < u8 > ( bit_stream . read_bits_big_endian ( 6 ) ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
if ( ( subframe_code > = 0b000010 & & subframe_code < = 0b000111 ) | | ( subframe_code > 0b001100 & & subframe_code < 0b100000 ) )
return LoaderError { LoaderError : : Category : : Format , static_cast < size_t > ( m_current_sample_or_frame ) , " Subframe type " } ;
2021-06-25 13:54:14 +02:00
FlacSubframeType subframe_type ;
u8 order = 0 ;
2021-09-06 03:29:52 +04:30
// LPC has the highest bit set
2021-06-25 13:54:14 +02:00
if ( ( subframe_code & 0b100000 ) > 0 ) {
subframe_type = FlacSubframeType : : LPC ;
order = ( subframe_code & 0b011111 ) + 1 ;
} else if ( ( subframe_code & 0b001000 ) > 0 ) {
// Fixed has the third-highest bit set
subframe_type = FlacSubframeType : : Fixed ;
order = ( subframe_code & 0b000111 ) ;
} else {
subframe_type = ( FlacSubframeType ) subframe_code ;
}
// wasted bits per sample (unary encoding)
bool has_wasted_bits = bit_stream . read_bit_big_endian ( ) ;
u8 k = 0 ;
if ( has_wasted_bits ) {
bool current_k_bit = 0 ;
do {
current_k_bit = bit_stream . read_bit_big_endian ( ) ;
+ + k ;
} while ( current_k_bit ! = 1 ) ;
}
return FlacSubframeHeader {
subframe_type ,
order ,
k ,
bits_per_sample
} ;
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
ErrorOr < Vector < i32 > , LoaderError > FlacLoaderPlugin : : parse_subframe ( FlacSubframeHeader & subframe_header , InputBitStream & bit_input )
2021-06-25 13:54:14 +02:00
{
Vector < i32 > samples ;
switch ( subframe_header . type ) {
case FlacSubframeType : : Constant : {
u64 constant_value = bit_input . read_bits_big_endian ( subframe_header . bits_per_sample - subframe_header . wasted_bits_per_sample ) ;
dbgln_if ( AFLACLOADER_DEBUG , " Constant subframe: {} " , constant_value ) ;
samples . ensure_capacity ( m_current_frame - > sample_count ) ;
2021-11-15 22:27:28 +01:00
VERIFY ( subframe_header . bits_per_sample - subframe_header . wasted_bits_per_sample ! = 0 ) ;
i32 constant = sign_extend ( static_cast < u32 > ( constant_value ) , subframe_header . bits_per_sample - subframe_header . wasted_bits_per_sample ) ;
2021-06-25 13:54:14 +02:00
for ( u32 i = 0 ; i < m_current_frame - > sample_count ; + + i ) {
2021-11-15 22:27:28 +01:00
samples . unchecked_append ( constant ) ;
2021-06-25 13:54:14 +02:00
}
break ;
}
case FlacSubframeType : : Fixed : {
dbgln_if ( AFLACLOADER_DEBUG , " Fixed LPC subframe order {} " , subframe_header . order ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
samples = TRY ( decode_fixed_lpc ( subframe_header , bit_input ) ) ;
2021-06-25 13:54:14 +02:00
break ;
}
case FlacSubframeType : : Verbatim : {
dbgln_if ( AFLACLOADER_DEBUG , " Verbatim subframe " ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
samples = TRY ( decode_verbatim ( subframe_header , bit_input ) ) ;
2021-06-25 13:54:14 +02:00
break ;
}
case FlacSubframeType : : LPC : {
dbgln_if ( AFLACLOADER_DEBUG , " Custom LPC subframe order {} " , subframe_header . order ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
samples = TRY ( decode_custom_lpc ( subframe_header , bit_input ) ) ;
2021-06-25 13:54:14 +02:00
break ;
}
default :
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
return LoaderError { LoaderError : : Category : : Unimplemented , static_cast < size_t > ( m_current_sample_or_frame ) , " Unhandled FLAC subframe type " } ;
2021-06-25 13:54:14 +02:00
}
for ( size_t i = 0 ; i < samples . size ( ) ; + + i ) {
samples [ i ] < < = subframe_header . wasted_bits_per_sample ;
}
ResampleHelper < i32 > resampler ( m_current_frame - > sample_rate , m_sample_rate ) ;
return resampler . resample ( samples ) ;
}
2021-08-03 18:01:22 +02:00
// Decode a subframe that isn't actually encoded, usually seen in random data
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
ErrorOr < Vector < i32 > , LoaderError > FlacLoaderPlugin : : decode_verbatim ( FlacSubframeHeader & subframe , InputBitStream & bit_input )
2021-06-25 13:54:14 +02:00
{
2021-08-03 18:01:22 +02:00
Vector < i32 > decoded ;
decoded . ensure_capacity ( m_current_frame - > sample_count ) ;
2021-11-15 22:27:28 +01:00
VERIFY ( subframe . bits_per_sample - subframe . wasted_bits_per_sample ! = 0 ) ;
2021-08-03 18:01:22 +02:00
for ( size_t i = 0 ; i < m_current_frame - > sample_count ; + + i ) {
2021-11-15 22:27:28 +01:00
decoded . unchecked_append ( sign_extend (
static_cast < u32 > ( bit_input . read_bits_big_endian ( subframe . bits_per_sample - subframe . wasted_bits_per_sample ) ) ,
subframe . bits_per_sample - subframe . wasted_bits_per_sample ) ) ;
2021-08-03 18:01:22 +02:00
}
return decoded ;
2021-06-25 13:54:14 +02:00
}
// Decode a subframe encoded with a custom linear predictor coding, i.e. the subframe provides the polynomial order and coefficients
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
ErrorOr < Vector < i32 > , LoaderError > FlacLoaderPlugin : : decode_custom_lpc ( FlacSubframeHeader & subframe , InputBitStream & bit_input )
2021-06-25 13:54:14 +02:00
{
Vector < i32 > decoded ;
decoded . ensure_capacity ( m_current_frame - > sample_count ) ;
2021-11-15 22:27:28 +01:00
VERIFY ( subframe . bits_per_sample - subframe . wasted_bits_per_sample ! = 0 ) ;
2021-06-25 13:54:14 +02:00
// warm-up samples
for ( auto i = 0 ; i < subframe . order ; + + i ) {
2021-11-15 22:27:28 +01:00
decoded . unchecked_append ( sign_extend (
static_cast < u32 > ( bit_input . read_bits_big_endian ( subframe . bits_per_sample - subframe . wasted_bits_per_sample ) ) ,
subframe . bits_per_sample - subframe . wasted_bits_per_sample ) ) ;
2021-06-25 13:54:14 +02:00
}
// precision of the coefficients
2021-11-15 22:27:28 +01:00
u8 lpc_precision = static_cast < u8 > ( bit_input . read_bits_big_endian ( 4 ) ) ;
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
if ( lpc_precision = = 0b1111 )
return LoaderError { LoaderError : : Category : : Format , static_cast < size_t > ( m_current_sample_or_frame ) , " Invalid linear predictor coefficient precision " } ;
2021-06-25 13:54:14 +02:00
lpc_precision + = 1 ;
// shift needed on the data (signed!)
2021-11-15 22:27:28 +01:00
i8 lpc_shift = sign_extend ( static_cast < u32 > ( bit_input . read_bits_big_endian ( 5 ) ) , 5 ) ;
2021-06-25 13:54:14 +02:00
Vector < i32 > coefficients ;
coefficients . ensure_capacity ( subframe . order ) ;
// read coefficients
for ( auto i = 0 ; i < subframe . order ; + + i ) {
2021-11-15 22:27:28 +01:00
u32 raw_coefficient = static_cast < u32 > ( bit_input . read_bits_big_endian ( lpc_precision ) ) ;
i32 coefficient = static_cast < i32 > ( sign_extend ( raw_coefficient , lpc_precision ) ) ;
2021-06-25 13:54:14 +02:00
coefficients . unchecked_append ( coefficient ) ;
}
2021-07-13 11:03:10 +02:00
dbgln_if ( AFLACLOADER_DEBUG , " {}-bit {} shift coefficients: {} " , lpc_precision , lpc_shift , coefficients ) ;
2021-06-25 13:54:14 +02:00
2021-12-17 00:00:03 +01:00
TRY ( decode_residual ( decoded , subframe , bit_input ) ) ;
2021-06-25 13:54:14 +02:00
// approximate the waveform with the predictor
for ( size_t i = subframe . order ; i < m_current_frame - > sample_count ; + + i ) {
2021-11-15 23:00:09 +01:00
// (see below)
2021-08-16 22:04:34 +02:00
i64 sample = 0 ;
2021-06-25 13:54:14 +02:00
for ( size_t t = 0 ; t < subframe . order ; + + t ) {
2021-11-15 23:00:09 +01:00
// It's really important that we compute in 64-bit land here.
// Even though FLAC operates at a maximum bit depth of 32 bits, modern encoders use super-large coefficients for maximum compression.
// These will easily overflow 32 bits and cause strange white noise that apruptly stops intermittently (at the end of a frame).
// The simple fix of course is to do intermediate computations in 64 bits.
2021-08-16 22:04:34 +02:00
sample + = static_cast < i64 > ( coefficients [ t ] ) * static_cast < i64 > ( decoded [ i - t - 1 ] ) ;
2021-06-25 13:54:14 +02:00
}
decoded [ i ] + = sample > > lpc_shift ;
}
return decoded ;
}
// Decode a subframe encoded with one of the fixed linear predictor codings
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
ErrorOr < Vector < i32 > , LoaderError > FlacLoaderPlugin : : decode_fixed_lpc ( FlacSubframeHeader & subframe , InputBitStream & bit_input )
2021-06-25 13:54:14 +02:00
{
Vector < i32 > decoded ;
decoded . ensure_capacity ( m_current_frame - > sample_count ) ;
2021-11-15 22:27:28 +01:00
VERIFY ( subframe . bits_per_sample - subframe . wasted_bits_per_sample ! = 0 ) ;
2021-06-25 13:54:14 +02:00
// warm-up samples
for ( auto i = 0 ; i < subframe . order ; + + i ) {
2021-11-15 22:27:28 +01:00
decoded . unchecked_append ( sign_extend (
static_cast < u32 > ( bit_input . read_bits_big_endian ( subframe . bits_per_sample - subframe . wasted_bits_per_sample ) ) ,
subframe . bits_per_sample - subframe . wasted_bits_per_sample ) ) ;
2021-06-25 13:54:14 +02:00
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
TRY ( decode_residual ( decoded , subframe , bit_input ) ) ;
2021-06-25 13:54:14 +02:00
dbgln_if ( AFLACLOADER_DEBUG , " decoded length {}, {} order predictor " , decoded . size ( ) , subframe . order ) ;
switch ( subframe . order ) {
case 0 :
// s_0(t) = 0
2021-07-11 14:47:09 +02:00
for ( u32 i = subframe . order ; i < m_current_frame - > sample_count ; + + i )
2021-06-25 13:54:14 +02:00
decoded [ i ] + = 0 ;
break ;
case 1 :
// s_1(t) = s(t-1)
2021-07-11 14:47:09 +02:00
for ( u32 i = subframe . order ; i < m_current_frame - > sample_count ; + + i )
2021-06-25 13:54:14 +02:00
decoded [ i ] + = decoded [ i - 1 ] ;
break ;
case 2 :
// s_2(t) = 2s(t-1) - s(t-2)
2021-07-11 14:47:09 +02:00
for ( u32 i = subframe . order ; i < m_current_frame - > sample_count ; + + i )
2021-06-25 13:54:14 +02:00
decoded [ i ] + = 2 * decoded [ i - 1 ] - decoded [ i - 2 ] ;
break ;
case 3 :
// s_3(t) = 3s(t-1) - 3s(t-2) + s(t-3)
2021-07-11 14:47:09 +02:00
for ( u32 i = subframe . order ; i < m_current_frame - > sample_count ; + + i )
2021-06-25 13:54:14 +02:00
decoded [ i ] + = 3 * decoded [ i - 1 ] - 3 * decoded [ i - 2 ] + decoded [ i - 3 ] ;
break ;
case 4 :
// s_4(t) = 4s(t-1) - 6s(t-2) + 4s(t-3) - s(t-4)
2021-07-11 14:47:09 +02:00
for ( u32 i = subframe . order ; i < m_current_frame - > sample_count ; + + i )
2021-06-25 13:54:14 +02:00
decoded [ i ] + = 4 * decoded [ i - 1 ] - 6 * decoded [ i - 2 ] + 4 * decoded [ i - 3 ] - decoded [ i - 4 ] ;
break ;
default :
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
return LoaderError { LoaderError : : Category : : Format , static_cast < size_t > ( m_current_sample_or_frame ) , String : : formatted ( " Unrecognized predictor order {} " , subframe . order ) } ;
2021-06-25 13:54:14 +02:00
}
return decoded ;
}
// Decode the residual, the "error" between the function approximation and the actual audio data
2021-12-17 00:00:03 +01:00
MaybeLoaderError FlacLoaderPlugin : : decode_residual ( Vector < i32 > & decoded , FlacSubframeHeader & subframe , InputBitStream & bit_input )
2021-06-25 13:54:14 +02:00
{
2021-11-15 22:27:28 +01:00
u8 residual_mode = static_cast < u8 > ( bit_input . read_bits_big_endian ( 2 ) ) ;
u8 partition_order = static_cast < u8 > ( bit_input . read_bits_big_endian ( 4 ) ) ;
2021-08-16 21:59:53 +02:00
size_t partitions = 1 < < partition_order ;
2021-06-25 13:54:14 +02:00
if ( residual_mode = = FlacResidualMode : : Rice4Bit ) {
// decode a single Rice partition with four bits for the order k
2021-08-16 21:59:53 +02:00
for ( size_t i = 0 ; i < partitions ; + + i ) {
2021-06-25 13:54:14 +02:00
auto rice_partition = decode_rice_partition ( 4 , partitions , i , subframe , bit_input ) ;
decoded . extend ( move ( rice_partition ) ) ;
}
} else if ( residual_mode = = FlacResidualMode : : Rice5Bit ) {
// five bits equivalent
2021-08-16 21:59:53 +02:00
for ( size_t i = 0 ; i < partitions ; + + i ) {
2021-06-25 13:54:14 +02:00
auto rice_partition = decode_rice_partition ( 5 , partitions , i , subframe , bit_input ) ;
decoded . extend ( move ( rice_partition ) ) ;
}
LibAudio: New error propagation API in Loader and Buffer
Previously, a libc-like out-of-line error information was used in the
loader and its plugins. Now, all functions that may fail to do their job
return some sort of Result. The universally-used error type ist the new
LoaderError, which can contain information about the general error
category (such as file format, I/O, unimplemented features), an error
description, and location information, such as file index or sample
index.
Additionally, the loader plugins try to do as little work as possible in
their constructors. Right after being constructed, a user should call
initialize() and check the errors returned from there. (This is done
transparently by Loader itself.) If a constructor caused an error, the
call to initialize should check and return it immediately.
This opportunity was used to rework a lot of the internal error
propagation in both loader classes, especially FlacLoader. Therefore, a
couple of other refactorings may have sneaked in as well.
The adoption of LibAudio users is minimal. Piano's adoption is not
important, as the code will receive major refactoring in the near future
anyways. SoundPlayer's adoption is also less important, as changes to
refactor it are in the works as well. aplay's adoption is the best and
may serve as an example for other users. It also includes new buffering
behavior.
Buffer also gets some attention, making it OOM-safe and thereby also
propagating its errors to the user.
2021-11-27 17:00:19 +01:00
} else
return LoaderError { LoaderError : : Category : : Format , static_cast < size_t > ( m_current_sample_or_frame ) , " Reserved residual coding method " } ;
2021-06-25 13:54:14 +02:00
2021-12-17 00:00:03 +01:00
return { } ;
2021-06-25 13:54:14 +02:00
}
// Decode a single Rice partition as part of the residual, every partition can have its own Rice parameter k
ALWAYS_INLINE Vector < i32 > FlacLoaderPlugin : : decode_rice_partition ( u8 partition_type , u32 partitions , u32 partition_index , FlacSubframeHeader & subframe , InputBitStream & bit_input )
{
// Rice parameter / Exp-Golomb order
2021-11-15 22:27:28 +01:00
u8 k = static_cast < u8 > ( bit_input . read_bits_big_endian ( partition_type ) ) ;
2021-06-25 13:54:14 +02:00
u32 residual_sample_count ;
if ( partitions = = 0 )
residual_sample_count = m_current_frame - > sample_count - subframe . order ;
else
residual_sample_count = m_current_frame - > sample_count / partitions ;
if ( partition_index = = 0 )
residual_sample_count - = subframe . order ;
Vector < i32 > rice_partition ;
rice_partition . resize ( residual_sample_count ) ;
// escape code for unencoded binary partition
if ( k = = ( 1 < < partition_type ) - 1 ) {
2021-11-15 22:27:28 +01:00
u8 unencoded_bps = static_cast < u8 > ( bit_input . read_bits_big_endian ( 5 ) ) ;
2021-08-16 21:59:53 +02:00
for ( size_t r = 0 ; r < residual_sample_count ; + + r ) {
2021-11-15 22:27:28 +01:00
rice_partition [ r ] = static_cast < u8 > ( bit_input . read_bits_big_endian ( unencoded_bps ) ) ;
2021-06-25 13:54:14 +02:00
}
} else {
2021-08-16 21:59:53 +02:00
for ( size_t r = 0 ; r < residual_sample_count ; + + r ) {
2021-06-25 13:54:14 +02:00
rice_partition [ r ] = decode_unsigned_exp_golomb ( k , bit_input ) ;
}
}
return rice_partition ;
}
// Decode a single number encoded with Rice/Exponential-Golomb encoding (the unsigned variant)
ALWAYS_INLINE i32 decode_unsigned_exp_golomb ( u8 k , InputBitStream & bit_input )
{
u8 q = 0 ;
while ( bit_input . read_bit_big_endian ( ) = = 0 )
+ + q ;
// least significant bits (remainder)
2021-11-15 22:27:28 +01:00
u32 rem = static_cast < u32 > ( bit_input . read_bits_big_endian ( k ) ) ;
u32 value = q < < k | rem ;
2021-06-25 13:54:14 +02:00
return rice_to_signed ( value ) ;
}
u64 read_utf8_char ( InputStream & input )
{
u64 character ;
2021-09-06 03:29:52 +04:30
u8 buffer = 0 ;
Bytes buffer_bytes { & buffer , 1 } ;
input . read ( buffer_bytes ) ;
u8 start_byte = buffer_bytes [ 0 ] ;
2021-06-25 13:54:14 +02:00
// Signal byte is zero: ASCII character
if ( ( start_byte & 0b10000000 ) = = 0 ) {
return start_byte ;
} else if ( ( start_byte & 0b11000000 ) = = 0b10000000 ) {
// illegal continuation byte
return 0 ;
}
// This algorithm is too good and supports the theoretical max 0xFF start byte
u8 length = 1 ;
while ( ( ( start_byte < < length ) & 0b10000000 ) = = 0b10000000 )
+ + length ;
u8 bits_from_start_byte = 8 - ( length + 1 ) ;
2021-07-17 18:29:28 +02:00
u8 start_byte_bitmask = AK : : exp2 ( bits_from_start_byte ) - 1 ;
2021-06-25 13:54:14 +02:00
character = start_byte_bitmask & start_byte ;
2021-07-21 15:58:57 +02:00
for ( u8 i = length - 1 ; i > 0 ; - - i ) {
2021-09-06 03:29:52 +04:30
input . read ( buffer_bytes ) ;
u8 current_byte = buffer_bytes [ 0 ] ;
2021-06-25 13:54:14 +02:00
character = ( character < < 6 ) | ( current_byte & 0b00111111 ) ;
}
return character ;
}
i64 sign_extend ( u32 n , u8 size )
{
// negative
if ( ( n & ( 1 < < ( size - 1 ) ) ) > 0 ) {
return static_cast < i64 > ( n | ( 0xffffffff < < size ) ) ;
}
// positive
return n ;
}
i32 rice_to_signed ( u32 x )
{
// positive numbers are even, negative numbers are odd
// bitmask for conditionally inverting the entire number, thereby "negating" it
2021-11-15 22:27:28 +01:00
i32 sign = - static_cast < i32 > ( x & 1 ) ;
2021-06-25 13:54:14 +02:00
// copies the sign's sign onto the actual magnitude of x
2021-11-15 22:27:28 +01:00
return static_cast < i32 > ( sign ^ ( x > > 1 ) ) ;
2021-06-25 13:54:14 +02:00
}
}