When the decoding of a track fails, `current_item_` is set to an invalid address, if the Crossfade option is enabled, the `Player::TrackAboutToEnd` method does not check whether `current_item_` is a valid pointer or not, causing a segmentation fault.
Player: Removed extra space
CollectionFilterWidget: Updated the tooltip, to reflect the changes.
CollectionQuery: Add parsing for SQL operators and insert right SQL
"where" searches.
Song: Add list of numerical columns
playlistfilterparser.cpp/FilterParser: move time and rating parsing
functions to new file:
searchparserutils.cpp: Contains common code used to parse search terms
in playlist and collection filters.
The idea is that Integrated Loudness is an integral part
of the song, much like knowing it's beginning / ending
in the file, and we must handle it the exact same way,
and pipe it through all the way.
At the same time, `EngineBase` knows Target Level (from settings),
and these two combined tell us the Gain needed to normalize the
Loudness of the particular Song (`EngineBase::Load()` does that).
So the actual backend only needs to handle the Volume.
We don't currently support changing Target Level on the fly.
We don't currently support changing Loudness-normalizing Gain on the fly.
This does not handle the case when the song is loaded from URL
and thus the EBU R 128 measures, that exist, are not nessesairly correct.
They end up being used in a quite a number of places later on,
it makes sense to have them in a common place.
Integrated Loudness (LUFS) is *usually* negative, so we really want to
always print a sign. But Loudness Range is non-negative.
I think it makes sense to print one or at most two decimal places for these.
Again, pretty boring boilerplate, rather identical to the handling of
other fields. We do need to be careful when [de]serializing it, though,
we don't want to accidentally loose the `NULL` (i.e. unknown) state!
Nothing really ground-breaking, just add those two fields
to each table that already has `bitrate`/`samplerate`/`bitdepth` fields.
Those new fields do need to be able to represent an invalid state
which is their default state, thus they are non-`NOT NULL`.
In principle, the actual field type could be `INTEGER`
(i.e. fixed point w/ 2 fractional digits), but unless we really want to
save a few bytes, it doesn't seem worthwhile.
FIXME: i'm not sure if `device-schema` should be changed too.
Jonas Kvinge
Adam Hill
BetterCallMolly
Michał Walenciak
Dakes
Roman Lebedev